From nicolas.frisby at gmail.com  Sat Jun  1 03:24:14 2019
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Fri, 31 May 2019 20:24:14 -0700
Subject: should TcCanonical.rewriteEvidence preserve ctev_nosh?
Message-ID: <CADfHYo7CN6zDaRNUVSO7G25o5wtVS-SbvgsLkXotgJJQ--hwyQ@mail.gmail.com>

A bit of context and then my question.

https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcCanonical.hs#L2226
declares `rewriteEvidence` with the comment that "rewriteEvidence old_ev
new_pred co  ... Returns a new_ev : new_pred, with same
wanted/given/derived flag as old_ev".

However, the `CtWanted` case just immediately calls `newWanted`, which
ignores the incoming `ctev_nosh` flag and always uses `WDeriv`.

```
rewriteEvidence ev@(CtWanted { ctev_dest = dest

                             , ctev_loc = loc }) new_pred co

= do { mb_new_ev <- newWanted loc new_pred
```

(This is true in 8.6.5 and also right now at
6febc444c0abea6c033174aa0e813c950b9b2877.)

Thus I'm seeing a [W] is become a [WD], which seems to contradict the
comment's "same flag" claim.

MY QUESTION ======> Is this "WD unsplitting" the intended behavior? See
canonicalization tc-trace below.

If it is intended, I'll probably write a follow-up question asking for more
advice. The constraint solver is looping unproductively because my plugin
keeps discarding the (re-)emitted [D] shadow as a tautology, then the [W]
"unsplits" during canonicalization (even though my plugin didn't touch the
[W]), this re-emits the same [D] (via a fundep), and so on.

My continual disclaimer recently is that I'm seeing this behavior with my
in-development plugin activated, so it's entirely I'm pushing GHC into
unfamiliar waters or even just plain violating some invariants without
realizing it. But this trace looks rather isolated from plugins.

Thanks! -Nick

Here's a -ddump-tc-trace of a canonicalization that goes from [W] to [WD]
happen (with GHC 8.6.5):

runStage canonicalization {
  workitem   =  [W] $dMonadFree_a35V {0}:: MonadFree
                                             ((fs_a2UF[sk:1] :- Const
e_a2UE[sk:1])
                                              :+ Const e_a2UE[sk:1])
                                             (Free fs_a2UF[sk:1]) (CDictCan)
flatten_args {
  (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]
  Free fs_a2UF[sk:1]
matchFamTcM
  Matching: (fs_a2UF[sk:1] :- Const e_a2UE[sk:1])
            :+ Const e_a2UE[sk:1]
  Match failed
matchFamTcM
  Matching: fs_a2UF[sk:1] :- Const e_a2UE[sk:1]
  Match failed
Unfilled tyvar fs_a2UF[sk:1]
Unfilled tyvar e_a2UE[sk:1]
flatten/flat-cache hit
  :- [* -> *, fs_a2UF[sk:1], Const e_a2UE[sk:1]]
  s_a35Z[fmv:1]
Unfilled tyvar s_a35Z[fmv:1]
Unfilled tyvar e_a2UE[sk:1]
matchFamTcM
  Matching: s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]
  Match failed
New coercion hole: co_a365
Emitting new coercion hole
  {co_a365} :: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
               GHC.Prim.~# s_a364[fmv:1]
extendFlatCache
  :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
  [WD]
  s_a364[fmv:1]
flatten/flat-cache miss
  :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
  s_a364[fmv:1]
  [WD] hole{co_a365} {0}:: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
                           GHC.Prim.~# s_a364[fmv:1]
Unfilled tyvar fs_a2UF[sk:1]
flatten }
  s_a364[fmv:1]
  Free fs_a2UF[sk:1]
Emitting new wanted
  $dMonadFree_a366 :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
  arising from a use of ‘wrap’ at tests/ill-typed/T7.hs:77:14-17
addTcEvBind
  a2V1
  [W] $dMonadFree_a35V
    = $dMonadFree_a366
      `cast` ((MonadFree
                 (Sym {co_a365} ; ((:+)
                                     <* -> *>_N (Sym {co_a360}) <Const
e_a2UE[sk:1]>_N)_N)
                 <Free fs_a2UF[sk:1]>_N)_R
              :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
                 ~R# MonadFree
                       ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const
e_a2UE[sk:1])
                       (Free fs_a2UF[sk:1]))
canClass
  [W] $dMonadFree_a35V {0}:: MonadFree
                               ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+
Const e_a2UE[sk:1])
                               (Free fs_a2UF[sk:1])
  MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
  ContinueWith [WD] $dMonadFree_a366 {0}:: MonadFree
                                             s_a364[fmv:1] (Free
fs_a2UF[sk:1])
end stage canonicalization }



and later




try_fundeps
  [WD] $dMonadFree_a36h {0}:: MonadFree
                                s_a36f[fmv:1] (Free fs_a2UF[sk:1])
(CDictCan)
emitFunDepDeriveds 1
  0
  [fs_a2UF[sk:1] ~ s_a36f[fmv:1]]
  False
Emitting new derived equality
  [D] _ {0}:: fs_a2UF[sk:1] GHC.Prim.~# s_a36f[fmv:1]




and then my plugin discards that [D] as a tautological, and then the [W]
gets unsplit and the [D] comes back around etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190531/693c41f4/attachment.html>

From takenobu.hs at gmail.com  Sat Jun  1 04:52:32 2019
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sat, 1 Jun 2019 13:52:32 +0900
Subject: Cmm syntax page on wiki
In-Reply-To: <DB7PR83MB0298A8EA7D2B89B47846F2AEAD190@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CAPB_NvyuEbwBA3g+Zhq=rKsE+TZWxcekan=ND00c_vwNfE+yOg@mail.gmail.com>
 <DB7PR83MB0298A8EA7D2B89B47846F2AEAD190@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAPB_NvxqgXfn2XUP1zFP3QbJCvhrd_Asq3WSvuP0DB-fVS3+YQ@mail.gmail.com>

Thank you so much, I added mutual links about code-gen and rts.
I'll tweak some more pages.

Regards,
Takenobu

On Sat, Jun 1, 2019 at 5:20 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
>
> Really good, thank you.
>
> Let's make sure it's discoverable.  Perhaps from the commentary, in at least two places:
>
> The description of code generation: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen
>
> The runtime system
> https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts
>
>
> And your new page could itself link back to those locations.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Takenobu Tani
> | Sent: 31 May 2019 13:04
> | To: ghc-devs <ghc-devs at haskell.org>
> | Subject: Cmm syntax page on wiki
> |
> | Hi devs,
> |
> | I wrote a wiki page for Cmm syntax [1] to improve readability for ghc
> | developers.
> |
> | Could you tell me if there are any problems or errors?
> | I'll update them or remove the page.
> |
> | [1]:
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> | askell.org%2Fghc%2Fghc%2Fwikis%2Fcommentary%2Fcompiler%2Fcmm-
> | syntax&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce396859157a54a0567d908
> | d6e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542023339
> | &amp;sdata=4DbAUYWd1bVM%2FDGuNctjBZgmYhCxazKnhGNN1CcLiJM%3D&amp;reserved=0
> |
> | Regards,
> | Takenobu
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce396859157a54a0567d908d6
> | e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542033347&a
> | mp;sdata=F6SDwM2XoZ3s58gWmzJu0OiMJshsxNxjGAT8AYzjgRI%3D&amp;reserved=0

From simonpj at microsoft.com  Sun Jun  2 15:32:47 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 2 Jun 2019 15:32:47 +0000
Subject: should TcCanonical.rewriteEvidence preserve ctev_nosh?
In-Reply-To: <CADfHYo7CN6zDaRNUVSO7G25o5wtVS-SbvgsLkXotgJJQ--hwyQ@mail.gmail.com>
References: <CADfHYo7CN6zDaRNUVSO7G25o5wtVS-SbvgsLkXotgJJQ--hwyQ@mail.gmail.com>
Message-ID: <DB7PR83MB0298AD93427A43EE8C09C364AD1B0@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Nick

That looks outright wrong to me.  Would you like to make a ticket for it?  It should be easy to fix.

I’m surprised it has not caused more trouble before now.

Well spotted and well diagnosed!

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Nicolas Frisby
Sent: 01 June 2019 04:24
To: ghc-devs at haskell.org
Subject: should TcCanonical.rewriteEvidence preserve ctev_nosh?

A bit of context and then my question.

https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcCanonical.hs#L2226<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%2Ftypecheck%2FTcCanonical.hs%23L2226&data=02%7C01%7Csimonpj%40microsoft.com%7Cd90efcd1da6f4058c00c08d6e640c7c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949563239275987&sdata=F7dgkceI2512TafrGNP38xvWAv2%2F6HKQscRnU%2Bypbf8%3D&reserved=0> declares `rewriteEvidence` with the comment that "rewriteEvidence old_ev new_pred co  ... Returns a new_ev : new_pred, with same wanted/given/derived flag as old_ev".

However, the `CtWanted` case just immediately calls `newWanted`, which ignores the incoming `ctev_nosh` flag and always uses `WDeriv`.

```
rewriteEvidence ev@(CtWanted { ctev_dest = dest

                             , ctev_loc = loc }) new_pred co

= do { mb_new_ev <- newWanted loc new_pred
```

(This is true in 8.6.5 and also right now at 6febc444c0abea6c033174aa0e813c950b9b2877.)

Thus I'm seeing a [W] is become a [WD], which seems to contradict the comment's "same flag" claim.

MY QUESTION ======> Is this "WD unsplitting" the intended behavior? See canonicalization tc-trace below.

If it is intended, I'll probably write a follow-up question asking for more advice. The constraint solver is looping unproductively because my plugin keeps discarding the (re-)emitted [D] shadow as a tautology, then the [W] "unsplits" during canonicalization (even though my plugin didn't touch the [W]), this re-emits the same [D] (via a fundep), and so on.

My continual disclaimer recently is that I'm seeing this behavior with my in-development plugin activated, so it's entirely I'm pushing GHC into unfamiliar waters or even just plain violating some invariants without realizing it. But this trace looks rather isolated from plugins.

Thanks! -Nick

Here's a -ddump-tc-trace of a canonicalization that goes from [W] to [WD] happen (with GHC 8.6.5):

runStage canonicalization {
  workitem   =  [W] $dMonadFree_a35V {0}:: MonadFree
                                             ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1])
                                              :+ Const e_a2UE[sk:1])
                                             (Free fs_a2UF[sk:1]) (CDictCan)
flatten_args {
  (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]
  Free fs_a2UF[sk:1]
matchFamTcM
  Matching: (fs_a2UF[sk:1] :- Const e_a2UE[sk:1])
            :+ Const e_a2UE[sk:1]
  Match failed
matchFamTcM
  Matching: fs_a2UF[sk:1] :- Const e_a2UE[sk:1]
  Match failed
Unfilled tyvar fs_a2UF[sk:1]
Unfilled tyvar e_a2UE[sk:1]
flatten/flat-cache hit
  :- [* -> *, fs_a2UF[sk:1], Const e_a2UE[sk:1]]
  s_a35Z[fmv:1]
Unfilled tyvar s_a35Z[fmv:1]
Unfilled tyvar e_a2UE[sk:1]
matchFamTcM
  Matching: s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]
  Match failed
New coercion hole: co_a365
Emitting new coercion hole
  {co_a365} :: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
               GHC.Prim.~# s_a364[fmv:1]
extendFlatCache
  :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
  [WD]
  s_a364[fmv:1]
flatten/flat-cache miss
  :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
  s_a364[fmv:1]
  [WD] hole{co_a365} {0}:: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
                           GHC.Prim.~# s_a364[fmv:1]
Unfilled tyvar fs_a2UF[sk:1]
flatten }
  s_a364[fmv:1]
  Free fs_a2UF[sk:1]
Emitting new wanted
  $dMonadFree_a366 :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
  arising from a use of ‘wrap’ at tests/ill-typed/T7.hs:77:14-17
addTcEvBind
  a2V1
  [W] $dMonadFree_a35V
    = $dMonadFree_a366
      `cast` ((MonadFree
                 (Sym {co_a365} ; ((:+)
                                     <* -> *>_N (Sym {co_a360}) <Const e_a2UE[sk:1]>_N)_N)
                 <Free fs_a2UF[sk:1]>_N)_R
              :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
                 ~R# MonadFree
                       ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1])
                       (Free fs_a2UF[sk:1]))
canClass
  [W] $dMonadFree_a35V {0}:: MonadFree
                               ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1])
                               (Free fs_a2UF[sk:1])
  MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
  ContinueWith [WD] $dMonadFree_a366 {0}:: MonadFree
                                             s_a364[fmv:1] (Free fs_a2UF[sk:1])
end stage canonicalization }



and later




try_fundeps
  [WD] $dMonadFree_a36h {0}:: MonadFree
                                s_a36f[fmv:1] (Free fs_a2UF[sk:1]) (CDictCan)
emitFunDepDeriveds 1
  0
  [fs_a2UF[sk:1] ~ s_a36f[fmv:1]]
  False
Emitting new derived equality
  [D] _ {0}:: fs_a2UF[sk:1] GHC.Prim.~# s_a36f[fmv:1]




and then my plugin discards that [D] as a tautological, and then the [W] gets unsplit and the [D] comes back around etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190602/7adf9fe2/attachment.html>

From nicolas.frisby at gmail.com  Sun Jun  2 19:15:16 2019
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Sun, 2 Jun 2019 12:15:16 -0700
Subject: should TcCanonical.rewriteEvidence preserve ctev_nosh?
In-Reply-To: <DB7PR83MB0298AD93427A43EE8C09C364AD1B0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CADfHYo7CN6zDaRNUVSO7G25o5wtVS-SbvgsLkXotgJJQ--hwyQ@mail.gmail.com>
 <DB7PR83MB0298AD93427A43EE8C09C364AD1B0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CADfHYo5+06+q9HXnCO6wtuKzo7nNTkaQf=5zF8MRZyun=5MRoA@mail.gmail.com>

Thank you for confirming, Simon.

I opened https://gitlab.haskell.org/ghc/ghc/issues/16735

On Sun, Jun 2, 2019 at 8:33 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Nick
>
>
>
> That looks outright wrong to me.  Would you like to make a ticket for it?
> It should be easy to fix.
>
>
>
> I’m surprised it has not caused more trouble before now.
>
>
>
> Well spotted and well diagnosed!
>
>
>
> Simon
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Nicolas
> Frisby
> *Sent:* 01 June 2019 04:24
> *To:* ghc-devs at haskell.org
> *Subject:* should TcCanonical.rewriteEvidence preserve ctev_nosh?
>
>
>
> A bit of context and then my question.
>
>
>
>
> https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcCanonical.hs#L2226
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%2Ftypecheck%2FTcCanonical.hs%23L2226&data=02%7C01%7Csimonpj%40microsoft.com%7Cd90efcd1da6f4058c00c08d6e640c7c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949563239275987&sdata=F7dgkceI2512TafrGNP38xvWAv2%2F6HKQscRnU%2Bypbf8%3D&reserved=0>
> declares `rewriteEvidence` with the comment that "rewriteEvidence old_ev
> new_pred co  ... Returns a new_ev : new_pred, with same
> wanted/given/derived flag as old_ev".
>
>
>
> However, the `CtWanted` case just immediately calls `newWanted`, which
> ignores the incoming `ctev_nosh` flag and always uses `WDeriv`.
>
>
> ```
> rewriteEvidence ev@(CtWanted { ctev_dest = dest
>
>                              , ctev_loc = loc }) new_pred co
>
> = do { mb_new_ev <- newWanted loc new_pred
> ```
>
>
>
> (This is true in 8.6.5 and also right now at
> 6febc444c0abea6c033174aa0e813c950b9b2877.)
>
>
>
> Thus I'm seeing a [W] is become a [WD], which seems to contradict the
> comment's "same flag" claim.
>
>
>
> MY QUESTION ======> Is this "WD unsplitting" the intended behavior? See
> canonicalization tc-trace below.
>
>
>
> If it is intended, I'll probably write a follow-up question asking for
> more advice. The constraint solver is looping unproductively because my
> plugin keeps discarding the (re-)emitted [D] shadow as a tautology, then
> the [W] "unsplits" during canonicalization (even though my plugin didn't
> touch the [W]), this re-emits the same [D] (via a fundep), and so on.
>
>
>
> My continual disclaimer recently is that I'm seeing this behavior with my
> in-development plugin activated, so it's entirely I'm pushing GHC into
> unfamiliar waters or even just plain violating some invariants without
> realizing it. But this trace looks rather isolated from plugins.
>
>
>
> Thanks! -Nick
>
>
>
> Here's a -ddump-tc-trace of a canonicalization that goes from [W] to [WD]
> happen (with GHC 8.6.5):
>
> runStage canonicalization {
>   workitem   =  [W] $dMonadFree_a35V {0}:: MonadFree
>                                              ((fs_a2UF[sk:1] :- Const
> e_a2UE[sk:1])
>                                               :+ Const e_a2UE[sk:1])
>                                              (Free fs_a2UF[sk:1])
> (CDictCan)
> flatten_args {
>   (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]
>   Free fs_a2UF[sk:1]
> matchFamTcM
>   Matching: (fs_a2UF[sk:1] :- Const e_a2UE[sk:1])
>             :+ Const e_a2UE[sk:1]
>   Match failed
> matchFamTcM
>   Matching: fs_a2UF[sk:1] :- Const e_a2UE[sk:1]
>   Match failed
> Unfilled tyvar fs_a2UF[sk:1]
> Unfilled tyvar e_a2UE[sk:1]
> flatten/flat-cache hit
>   :- [* -> *, fs_a2UF[sk:1], Const e_a2UE[sk:1]]
>   s_a35Z[fmv:1]
> Unfilled tyvar s_a35Z[fmv:1]
> Unfilled tyvar e_a2UE[sk:1]
> matchFamTcM
>   Matching: s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]
>   Match failed
> New coercion hole: co_a365
> Emitting new coercion hole
>   {co_a365} :: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
>                GHC.Prim.~# s_a364[fmv:1]
> extendFlatCache
>   :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
>   [WD]
>   s_a364[fmv:1]
> flatten/flat-cache miss
>   :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
>   s_a364[fmv:1]
>   [WD] hole{co_a365} {0}:: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
>                            GHC.Prim.~# s_a364[fmv:1]
> Unfilled tyvar fs_a2UF[sk:1]
> flatten }
>   s_a364[fmv:1]
>   Free fs_a2UF[sk:1]
> Emitting new wanted
>   $dMonadFree_a366 :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>   arising from a use of ‘wrap’ at tests/ill-typed/T7.hs:77:14-17
> addTcEvBind
>   a2V1
>   [W] $dMonadFree_a35V
>     = $dMonadFree_a366
>       `cast` ((MonadFree
>                  (Sym {co_a365} ; ((:+)
>                                      <* -> *>_N (Sym {co_a360}) <Const
> e_a2UE[sk:1]>_N)_N)
>                  <Free fs_a2UF[sk:1]>_N)_R
>               :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>                  ~R# MonadFree
>                        ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const
> e_a2UE[sk:1])
>                        (Free fs_a2UF[sk:1]))
> canClass
>   [W] $dMonadFree_a35V {0}:: MonadFree
>                                ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+
> Const e_a2UE[sk:1])
>                                (Free fs_a2UF[sk:1])
>   MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>   ContinueWith [WD] $dMonadFree_a366 {0}:: MonadFree
>                                              s_a364[fmv:1] (Free
> fs_a2UF[sk:1])
> end stage canonicalization }
>
>
>
>
>
>
>
> and later
>
>
>
>
>
>
>
>
>
> try_fundeps
>   [WD] $dMonadFree_a36h {0}:: MonadFree
>                                 s_a36f[fmv:1] (Free fs_a2UF[sk:1])
> (CDictCan)
> emitFunDepDeriveds 1
>   0
>   [fs_a2UF[sk:1] ~ s_a36f[fmv:1]]
>   False
> Emitting new derived equality
>   [D] _ {0}:: fs_a2UF[sk:1] GHC.Prim.~# s_a36f[fmv:1]
>
>
>
>
>
>
>
>
>
> and then my plugin discards that [D] as a tautological, and then the [W]
> gets unsplit and the [D] comes back around etc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190602/0c55a850/attachment.html>

From simonpj at microsoft.com  Mon Jun  3 14:03:37 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Jun 2019 14:03:37 +0000
Subject: Pushing to gitlab.haskell.org
Message-ID: <DB7PR83MB029842836D7B8B0ABD98247FAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Devs
Suddenly I can't push to (a non-master branch on) gitlab.haskell.org.
In .git/config I have

[remote "origin"]

  url = https://gitlab.haskell.org/ghc/ghc

  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin

  merge = refs/heads/master
An attempt to push leads to a request for a username.  If I enter one, a request for a password.

simonpj at MSRC-3645512:~/code/HEAD$ git push origin wip/T16735

Username for 'https://gitlab.haskell.org':   C-c C-c
I thought I had SSH keys uploaded.  But in fact I found that my id_rsa.pub was a bit different to the one in gitlab.  Not sure _how_ that happened, or why it hasn't bitten before.
So I uploaded a new id_rsa.pub key.
Same behaviour.
So I tried ssh -v gitlab.haskell.org, and got the output below.   It seems to skip id_dsa, but doesn't even try id_rsa.
Can anyone help? This is tiresome.
Thanks
Simon


simonpj at MSRC-3645512:~/code/HEAD$ ssh -v gitlab.haskell.org

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017

debug1: Reading configuration data /home/simonpj/.ssh/config

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug1: Connecting to gitlab.haskell.org [2604:1380:0:8900::3] port 22.

debug1: Connection established.

debug1: identity file /home/simonpj/.ssh/id_rsa type 0

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1

debug1: identity file /home/simonpj/.ssh/id_dsa type 1

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9

debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000

debug1: Authenticating to gitlab.haskell.org:22 as 'simonpj'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256 at libssh.org

debug1: kex: host key algorithm: ssh-ed25519

debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ssh-ed25519 SHA256:wtE9yoEHLsotzqKfbDs1JIqR+c8ZZyW+FAJAmteBfcI

debug1: Host 'gitlab.haskell.org' is known and matches the ED25519 host key.

debug1: Found key in /home/simonpj/.ssh/known_hosts:7

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: rekey after 134217728 blocks

debug1: Skipping ssh-dss key /home/simonpj/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering public key: RSA SHA256:H1l824hIxHozwRuEqdaYJjW10mRRlQVUhxREvuseqtU /home/simonpj/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Trying private key: /home/simonpj/.ssh/id_ecdsa

debug1: Trying private key: /home/simonpj/.ssh/id_ed25519

debug1: Next authentication method: keyboard-interactive

Password:   C-c C-c



simonpj at MSRC-3645512:~/code/HEAD$


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

From mail at nh2.me  Mon Jun  3 14:18:56 2019
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Mon, 3 Jun 2019 16:18:56 +0200
Subject: Pushing to gitlab.haskell.org
In-Reply-To: <DB7PR83MB029842836D7B8B0ABD98247FAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB029842836D7B8B0ABD98247FAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <0fa0a4a0-17bf-39aa-2733-8a648566e016@nh2.me>

Hey Simon,

you mention SSH keys, but in your quoted config I can see HTTPS, not SSH:

> [remote "origin"]
>   url = https://gitlab.haskell.org/ghc/ghc

Should this perhaps be

    url = git at gitlab.haskell.org:ghc/ghc.git

instead?

> So I tried ssh -v gitlab.haskell.org

You need to include the user name "git" for this. Otherwise it will try to use your local user name on the remote server.
This is the command to run and the output you should get if it's working:

    $ ssh git at gitlab.haskell.org
    PTY allocation request failed on channel 0
    Welcome to GitLab, @nh2!
    Connection to gitlab.haskell.org closed.

Hope this helps,

Niklas

From simonpj at microsoft.com  Mon Jun  3 16:34:20 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Jun 2019 16:34:20 +0000
Subject: Pushing to gitlab.haskell.org
In-Reply-To: <CALuQ0m9OBUj=S94E0HVoLz+=nN1avy1pEhdO4KhPs8tUZvOu5w@mail.gmail.com>
References: <DB7PR83MB029842836D7B8B0ABD98247FAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CALuQ0m9OBUj=S94E0HVoLz+=nN1avy1pEhdO4KhPs8tUZvOu5w@mail.gmail.com>
Message-ID: <DB7PR83MB0298CAEDCA5B68D35341ECE8AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>

|  You probably need to use the "git@" remote.
|  
|  git at gitlab.haskell.org:ghc/ghc.git
|  
|  git remote set-url origin git at gitlab.haskell.org:ghc/ghc.git

Correct!  I don't know how this worked before. (Maybe it never did; this is a relatively new machine.)

Maybe we should change the guidance on
https://gitlab.haskell.org/ghc/ghc/wikis/building/getting-the-sources

to give the git url?  Or does that /require/ ssh and hence exclude some folk?

Simon

|  -----Original Message-----
|  From: Matthew Pickering <matthewtpickering at gmail.com>
|  Sent: 03 June 2019 15:08
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Subject: Re: Pushing to gitlab.haskell.org
|  
|  You probably need to use the "git@" remote.
|  
|  git at gitlab.haskell.org:ghc/ghc.git
|  
|  git remote set-url origin git at gitlab.haskell.org:ghc/ghc.git
|  
|  
|  On Mon, Jun 3, 2019 at 3:04 PM Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org> wrote:
|  >
|  > Devs
|  >
|  > Suddenly I can’t push to (a non-master branch on) gitlab.haskell.org.
|  >
|  > In .git/config I have
|  >
|  > [remote "origin"]
|  >
|  >   url =
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc&amp;data=02%7C01%7Csimonpj%40microsoft.com%
|  > 7C186b15a68a134060a1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%
|  > 7C1%7C0%7C636951676910548930&amp;sdata=cTjUrROo3Dje%2FlbiFdtUPadlFUPsN
|  > 2OWUgLIOYv%2BL8o%3D&amp;reserved=0
|  >
|  >   fetch = +refs/heads/*:refs/remotes/origin/*
|  >
|  > [branch "master"]
|  >
|  >   remote = origin
|  >
|  >   merge = refs/heads/master
|  >
|  > An attempt to push leads to a request for a username.  If I enter one, a
|  request for a password.
|  >
|  > simonpj at MSRC-3645512:~/code/HEAD$ git push origin wip/T16735
|  >
|  > Username for
|  'https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
|  haskell.org&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C186b15a68a134060a
|  1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369516769105
|  48930&amp;sdata=O%2F%2B7WovumSLxe8%2FXrh1NpowWs%2FYVqhdEsDCsM5diz%2Bk%3D&a
|  mp;reserved=0':   C-c C-c
|  >
|  > I thought I had SSH keys uploaded.  But in fact I found that my
|  id_rsa.pub was a bit different to the one in gitlab.  Not sure _how_ that
|  happened, or why it hasn’t bitten before.
|  >
|  > So I uploaded a new id_rsa.pub key.
|  >
|  > Same behaviour.
|  >
|  > So I tried ssh -v gitlab.haskell.org, and got the output below.   It
|  seems to skip id_dsa, but doesn’t even try id_rsa.
|  >
|  > Can anyone help? This is tiresome.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > simonpj at MSRC-3645512:~/code/HEAD$ ssh -v gitlab.haskell.org
|  >
|  > OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
|  >
|  > debug1: Reading configuration data /home/simonpj/.ssh/config
|  >
|  > debug1: Reading configuration data /etc/ssh/ssh_config
|  >
|  > debug1: /etc/ssh/ssh_config line 19: Applying options for *
|  >
|  > debug1: Connecting to gitlab.haskell.org [2604:1380:0:8900::3] port 22.
|  >
|  > debug1: Connection established.
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_ed25519 type -1
|  >
|  > debug1: key_load_public: No such file or directory
|  >
|  > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
|  >
|  > debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
|  >
|  > debug1: Remote protocol version 2.0, remote software version
|  > OpenSSH_7.9
|  >
|  > debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
|  >
|  > debug1: Authenticating to gitlab.haskell.org:22 as 'simonpj'
|  >
|  > debug1: SSH2_MSG_KEXINIT sent
|  >
|  > debug1: SSH2_MSG_KEXINIT received
|  >
|  > debug1: kex: algorithm: curve25519-sha256 at libssh.org
|  >
|  > debug1: kex: host key algorithm: ssh-ed25519
|  >
|  > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
|  > <implicit> compression: none
|  >
|  > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
|  > <implicit> compression: none
|  >
|  > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
|  >
|  > debug1: Server host key: ssh-ed25519
|  > SHA256:wtE9yoEHLsotzqKfbDs1JIqR+c8ZZyW+FAJAmteBfcI
|  >
|  > debug1: Host 'gitlab.haskell.org' is known and matches the ED25519 host
|  key.
|  >
|  > debug1: Found key in /home/simonpj/.ssh/known_hosts:7
|  >
|  > debug1: rekey after 134217728 blocks
|  >
|  > debug1: SSH2_MSG_NEWKEYS sent
|  >
|  > debug1: expecting SSH2_MSG_NEWKEYS
|  >
|  > debug1: SSH2_MSG_NEWKEYS received
|  >
|  > debug1: rekey after 134217728 blocks
|  >
|  > debug1: Skipping ssh-dss key /home/simonpj/.ssh/id_dsa - not in
|  > PubkeyAcceptedKeyTypes
|  >
|  > debug1: SSH2_MSG_EXT_INFO received
|  >
|  > debug1: kex_input_ext_info:
|  > server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss
|  > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
|  >
|  > debug1: SSH2_MSG_SERVICE_ACCEPT received
|  >
|  > debug1: Authentications that can continue:
|  > publickey,password,keyboard-interactive
|  >
|  > debug1: Next authentication method: publickey
|  >
|  > debug1: Offering public key: RSA
|  > SHA256:H1l824hIxHozwRuEqdaYJjW10mRRlQVUhxREvuseqtU
|  > /home/simonpj/.ssh/id_rsa
|  >
|  > debug1: Authentications that can continue:
|  > publickey,password,keyboard-interactive
|  >
|  > debug1: Trying private key: /home/simonpj/.ssh/id_ecdsa
|  >
|  > debug1: Trying private key: /home/simonpj/.ssh/id_ed25519
|  >
|  > debug1: Next authentication method: keyboard-interactive
|  >
|  > Password:   C-c C-c
|  >
|  >
|  >
|  > simonpj at MSRC-3645512:~/code/HEAD$
|  >
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
|  > %7Csimonpj%40microsoft.com%7C186b15a68a134060a1bd08d6e82ce8b3%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636951676910548930&amp;sdata=d3AF
|  > 6HM%2B48XW8mZJ42m%2FSngTPiVEERDM24th%2BZMY%2BPA%3D&amp;reserved=0

From simonpj at microsoft.com  Mon Jun  3 16:45:49 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Jun 2019 16:45:49 +0000
Subject: Wiki markup
Message-ID: <DB7PR83MB02981B8EA28A5FF4C631DC6DAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>

This is a GitLab wiki markup question.
Suppose I want to have a bulleted list, in which a single item has some text, then some laid-out code, then more text.  I want the second blob of text to be indented as part of the bullet.
Absent the laid-out code, indenting the second para 2 spaces seems to do it:

* first bit of text



  Second bit of text
But if there is code in the middle, like this

* first bit of text

```

code

```

  Second bit of text
the second bit of text is not indented.
Does anyone know how to achieve the indentation?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/7d5a657f/attachment.html>

From simonpj at microsoft.com  Mon Jun  3 16:48:12 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Jun 2019 16:48:12 +0000
Subject: setsockopt IPV2_TCLASS 8
Message-ID: <DB7PR83MB0298A01CC1A58B46DB0A5695AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I'm getting a lot of these messages from ssh when using git

setsockopt IPV6_TCLASS 8: Operation not permitted:
(Same thing when directly invoking ssh git at gitlab.haskell.org<mailto:git at gitlab.haskell.org>)
Should I worry?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/3d74b0fc/attachment.html>

From allbery.b at gmail.com  Mon Jun  3 16:59:15 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 3 Jun 2019 12:59:15 -0400
Subject: setsockopt IPV2_TCLASS 8
In-Reply-To: <DB7PR83MB0298A01CC1A58B46DB0A5695AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB0298A01CC1A58B46DB0A5695AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAKFCL4Vjas4ya5Ac8hcfzN2xr_h+1POW=-fmMnymc1QVaS5jbA@mail.gmail.com>

A quick search suggests this is a WSL shortcoming and is harmless.

On Mon, Jun 3, 2019 at 12:48 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> I’m getting a lot of these messages from ssh when using git
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> (Same thing when directly invoking ssh git at gitlab.haskell.org)
>
> Should I worry?
>
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/695664b6/attachment.html>

From allbery.b at gmail.com  Mon Jun  3 17:03:09 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 3 Jun 2019 13:03:09 -0400
Subject: Pushing to gitlab.haskell.org
In-Reply-To: <DB7PR83MB0298CAEDCA5B68D35341ECE8AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB029842836D7B8B0ABD98247FAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CALuQ0m9OBUj=S94E0HVoLz+=nN1avy1pEhdO4KhPs8tUZvOu5w@mail.gmail.com>
 <DB7PR83MB0298CAEDCA5B68D35341ECE8AD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAKFCL4Wg1z3zhqRh4WhrOdN4H+0NAJcT6QVf6bbGEOeXFDpQsA@mail.gmail.com>

Exactly. Also it makes some sense to use https for fetch but ssh for push;
that's how I have my own repos and those for various other projects set up.

On Mon, Jun 3, 2019 at 12:34 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> |  You probably need to use the "git@" remote.
> |
> |  git at gitlab.haskell.org:ghc/ghc.git
> |
> |  git remote set-url origin git at gitlab.haskell.org:ghc/ghc.git
>
> Correct!  I don't know how this worked before. (Maybe it never did; this
> is a relatively new machine.)
>
> Maybe we should change the guidance on
> https://gitlab.haskell.org/ghc/ghc/wikis/building/getting-the-sources
>
> to give the git url?  Or does that /require/ ssh and hence exclude some
> folk?
>
> Simon
>
> |  -----Original Message-----
> |  From: Matthew Pickering <matthewtpickering at gmail.com>
> |  Sent: 03 June 2019 15:08
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Subject: Re: Pushing to gitlab.haskell.org
> |
> |  You probably need to use the "git@" remote.
> |
> |  git at gitlab.haskell.org:ghc/ghc.git
> |
> |  git remote set-url origin git at gitlab.haskell.org:ghc/ghc.git
> |
> |
> |  On Mon, Jun 3, 2019 at 3:04 PM Simon Peyton Jones via ghc-devs <ghc-
> |  devs at haskell.org> wrote:
> |  >
> |  > Devs
> |  >
> |  > Suddenly I can’t push to (a non-master branch on) gitlab.haskell.org.
> |  >
> |  > In .git/config I have
> |  >
> |  > [remote "origin"]
> |  >
> |  >   url =
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %
> |  > 7C186b15a68a134060a1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%
> |  > 7C1%7C0%7C636951676910548930&amp;sdata=cTjUrROo3Dje%2FlbiFdtUPadlFUPsN
> |  > 2OWUgLIOYv%2BL8o%3D&amp;reserved=0
> |  >
> |  >   fetch = +refs/heads/*:refs/remotes/origin/*
> |  >
> |  > [branch "master"]
> |  >
> |  >   remote = origin
> |  >
> |  >   merge = refs/heads/master
> |  >
> |  > An attempt to push leads to a request for a username.  If I enter
> one, a
> |  request for a password.
> |  >
> |  > simonpj at MSRC-3645512:~/code/HEAD$ git push origin wip/T16735
> |  >
> |  > Username for
> |  '
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
> |  haskell.org&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C186b15a68a134060a
> |
> 1bd08d6e82ce8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369516769105
> |
> 48930&amp;sdata=O%2F%2B7WovumSLxe8%2FXrh1NpowWs%2FYVqhdEsDCsM5diz%2Bk%3D&a
> |  mp;reserved=0':   C-c C-c
> |  >
> |  > I thought I had SSH keys uploaded.  But in fact I found that my
> |  id_rsa.pub was a bit different to the one in gitlab.  Not sure _how_
> that
> |  happened, or why it hasn’t bitten before.
> |  >
> |  > So I uploaded a new id_rsa.pub key.
> |  >
> |  > Same behaviour.
> |  >
> |  > So I tried ssh -v gitlab.haskell.org, and got the output below.   It
> |  seems to skip id_dsa, but doesn’t even try id_rsa.
> |  >
> |  > Can anyone help? This is tiresome.
> |  >
> |  > Thanks
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > simonpj at MSRC-3645512:~/code/HEAD$ ssh -v gitlab.haskell.org
> |  >
> |  > OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
> |  >
> |  > debug1: Reading configuration data /home/simonpj/.ssh/config
> |  >
> |  > debug1: Reading configuration data /etc/ssh/ssh_config
> |  >
> |  > debug1: /etc/ssh/ssh_config line 19: Applying options for *
> |  >
> |  > debug1: Connecting to gitlab.haskell.org [2604:1380:0:8900::3] port
> 22.
> |  >
> |  > debug1: Connection established.
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ed25519 type -1
> |  >
> |  > debug1: key_load_public: No such file or directory
> |  >
> |  > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> |  >
> |  > debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
> |  >
> |  > debug1: Remote protocol version 2.0, remote software version
> |  > OpenSSH_7.9
> |  >
> |  > debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
> |  >
> |  > debug1: Authenticating to gitlab.haskell.org:22 as 'simonpj'
> |  >
> |  > debug1: SSH2_MSG_KEXINIT sent
> |  >
> |  > debug1: SSH2_MSG_KEXINIT received
> |  >
> |  > debug1: kex: algorithm: curve25519-sha256 at libssh.org
> |  >
> |  > debug1: kex: host key algorithm: ssh-ed25519
> |  >
> |  > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com
> MAC:
> |  > <implicit> compression: none
> |  >
> |  > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com
> MAC:
> |  > <implicit> compression: none
> |  >
> |  > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> |  >
> |  > debug1: Server host key: ssh-ed25519
> |  > SHA256:wtE9yoEHLsotzqKfbDs1JIqR+c8ZZyW+FAJAmteBfcI
> |  >
> |  > debug1: Host 'gitlab.haskell.org' is known and matches the ED25519
> host
> |  key.
> |  >
> |  > debug1: Found key in /home/simonpj/.ssh/known_hosts:7
> |  >
> |  > debug1: rekey after 134217728 blocks
> |  >
> |  > debug1: SSH2_MSG_NEWKEYS sent
> |  >
> |  > debug1: expecting SSH2_MSG_NEWKEYS
> |  >
> |  > debug1: SSH2_MSG_NEWKEYS received
> |  >
> |  > debug1: rekey after 134217728 blocks
> |  >
> |  > debug1: Skipping ssh-dss key /home/simonpj/.ssh/id_dsa - not in
> |  > PubkeyAcceptedKeyTypes
> |  >
> |  > debug1: SSH2_MSG_EXT_INFO received
> |  >
> |  > debug1: kex_input_ext_info:
> |  > server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss
> |  > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
> |  >
> |  > debug1: SSH2_MSG_SERVICE_ACCEPT received
> |  >
> |  > debug1: Authentications that can continue:
> |  > publickey,password,keyboard-interactive
> |  >
> |  > debug1: Next authentication method: publickey
> |  >
> |  > debug1: Offering public key: RSA
> |  > SHA256:H1l824hIxHozwRuEqdaYJjW10mRRlQVUhxREvuseqtU
> |  > /home/simonpj/.ssh/id_rsa
> |  >
> |  > debug1: Authentications that can continue:
> |  > publickey,password,keyboard-interactive
> |  >
> |  > debug1: Trying private key: /home/simonpj/.ssh/id_ecdsa
> |  >
> |  > debug1: Trying private key: /home/simonpj/.ssh/id_ed25519
> |  >
> |  > debug1: Next authentication method: keyboard-interactive
> |  >
> |  > Password:   C-c C-c
> |  >
> |  >
> |  >
> |  > simonpj at MSRC-3645512:~/code/HEAD$
> |  >
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
> .
> |  > haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
> |  > %7Csimonpj%40microsoft.com
> %7C186b15a68a134060a1bd08d6e82ce8b3%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636951676910548930&amp;sdata=d3AF
> |  > 6HM%2B48XW8mZJ42m%2FSngTPiVEERDM24th%2BZMY%2BPA%3D&amp;reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/b4717a95/attachment.html>

From fryguybob at gmail.com  Mon Jun  3 17:15:09 2019
From: fryguybob at gmail.com (Ryan Yates)
Date: Mon, 3 Jun 2019 13:15:09 -0400
Subject: Wiki markup
In-Reply-To: <DB7PR83MB02981B8EA28A5FF4C631DC6DAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB02981B8EA28A5FF4C631DC6DAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAO27hRpM6gYnu-Wf=JyqaWyidv0S27TOh8_OkNvheQsA8UJMGw@mail.gmail.com>

Hi Simon,

I think you can just indent the code block to achieve this.

Ryan

On Mon, Jun 3, 2019 at 12:46 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> This is a GitLab wiki markup question.
>
> Suppose I want to have a bulleted list, in which a single item has some
> text, then some laid-out code, then more text.  I want the second blob of
> text to be indented as part of the bullet.
>
> Absent the laid-out code, indenting the second para 2 spaces seems to do
> it:
>
> * first bit of text
>
>
>
>   Second bit of text
>
> But if there is code in the middle, like this
>
> * first bit of text
>
> ```
>
> code
>
> ```
>
>   Second bit of text
>
> the second bit of text is not indented.
>
> Does anyone know how to achieve the indentation?
>
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/babd4ed3/attachment.html>

From carter.schonwald at gmail.com  Tue Jun  4 00:53:18 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 3 Jun 2019 20:53:18 -0400
Subject: Container type classes
In-Reply-To: <DB7PR83MB029830C6DEAAF5BF37EAE218AD1F0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <mailman.4.1558785601.1795.ghc-devs@haskell.org>
 <5CEE6371.2010406@gmx.at>
 <CAGK9nupahaNgeOoscgJ-zaBCDRN17fKTap-cn_Ar9v6gMGoweg@mail.gmail.com>
 <DB7PR83MB029830C6DEAAF5BF37EAE218AD1F0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAHYVw0yfy-Cfd1BrSLh+DfvqVBdC3zKT2F9Y0MkV0xx=5fABvw@mail.gmail.com>

http://hackage.haskell.org/package/EdisonCore

the Edison packages come to mind as a previous effort in this space

On Wed, May 29, 2019 at 4:08 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> | having a common pattern for naming the operations certainly seems
> | nice.   I am ambivalent if we do this with a class, or just name the
> | operations the same way, and use the module system.
>
> This was my reaction too.  Consistent naming, yes.  Using a type class,
> when every invocation is at a statically known type (i.e. not leveraging
> the type class) seems less good.
>
> For example, eqType :: Type -> Type -> Bool, and I can search for every
> invocation of eqType.  That can be very useful.  Searching for every use of
> (==) and figuring out which of those zillions of calls are for equality of
> Type, is much less attractive.
>
> But I'm not going to die in the trenches for this.  You are doing us a
> service by making everything systematic.  The code that is finally executed
> will, I hope and believe, be the same either way.
>
> Simon
>
>
>  The type hackery I
> | was referring to was the type family for the set elements and map
> | keys you were referring to.    It looks like the maps we have are
> | uniform enough that one type family per class does the job, so I think
> the
> | class you came with looks nice.
> |
> | -Iavor
> | PS: the type hacker I was referring to was  having to add more type
> | families, for example if we had a map that can only store one type of
> | elements, but it looks like this is not the case here.
> |
> |
> | On Wed, May 29, 2019 at 3:48 AM Andreas Klebinger
> | <klebinger.andreas at gmx.at> wrote:
> | >
> | > ghc-devs-request at haskell.org schrieb:
> | > > Hello,
> | > >
> | > > I think refactoring to use consistent naming is a good idea, but I
> | > > am not sure about the class idea.
> | > >
> | > > To see if it is viable, we should list the types in question and the
> | > > operations we'd like to overload.
> | > >
> | > > I find that with containers there tend to be two cases: either the
> | > > operations are similar but not exactly the same and you have to do
> | > > type hackery to make things fit, or you realize that you can just
> | > > use the same type in multiple places.
> | > >
> | > > Iavor
> | > The function prototype are already part of the merge request. See here:
> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> | > ab.haskell.org%2Fghc%2Fghc%2Fblob%2Fa0781d746c223636a90a0837fe678aab5b
> | > 70e4b6%2Fcompiler%2Fstructures%2FCollections.hs&amp;data=02%7C01%7Csim
> | > onpj%40microsoft.com%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988bf86f1
> | > 41af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&amp;sdata=lgu4jc9g3x
> | > H%2B9nDorkvPZjts9L1RpVLpexed1uJnyXA%3D&amp;reserved=0
> | >
> | > As for the data structures in question these are:
> | > * EnumSet
> | > * Data.IntSet
> | > * Data.Set
> | > * UniqSet
> | > * UniqDSet
> | >
> | > * Data.IntMap
> | > * Data.Map
> | > * LabelMap
> | > * UniqFM
> | > * UniqDFM
> | > * UniqMap
> | >
> | > * Maybe the TrieMap Variants
> | >
> | > Maybe I missed some but these are all I can think of currently. But
> | > they are already plenty.
> | >
> | > Imo using type classes IS a kind of type hackery required "to make
> | > things fit".
> | > _______________________________________________
> | > ghc-devs mailing list
> | > ghc-devs at haskell.org
> | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
> | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
> | > %7Csimonpj%40microsoft.com%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988
> | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&amp;sdata=fjw2
> | > XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&amp;reserved=0
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C4fe7780126ff475c3c7308d6
> |
> e45e8586%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&a
> |
> mp;sdata=fjw2XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&amp;reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/74146712/attachment-0001.html>

From takenobu.hs at gmail.com  Tue Jun  4 08:22:13 2019
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 4 Jun 2019 17:22:13 +0900
Subject: Wiki markup
In-Reply-To: <CAO27hRpM6gYnu-Wf=JyqaWyidv0S27TOh8_OkNvheQsA8UJMGw@mail.gmail.com>
References: <DB7PR83MB02981B8EA28A5FF4C631DC6DAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAO27hRpM6gYnu-Wf=JyqaWyidv0S27TOh8_OkNvheQsA8UJMGw@mail.gmail.com>
Message-ID: <CAPB_NvxEgzm-9OMoUA3L297M51z9-Bn9YYq6HqykZfXDwvO9YA@mail.gmail.com>

It may be solved already, but this is supplementary information.
As Ryan says, you can adjust it with indents as follows:.

* first bit of text

  ```  <--- Align the number of indent characters
  code
  ```

  Second bit of text



Here is an example of markdown:
  https://gitlab.haskell.org/ghc/ghc/wikis/sand-box

This is the GitLab markdown specification:
  https://docs.gitlab.com/ee/user/markdown.html#lists


Regards,
Takenobu

On Tue, Jun 4, 2019 at 2:15 AM Ryan Yates <fryguybob at gmail.com> wrote:
>
> Hi Simon,
>
> I think you can just indent the code block to achieve this.
>
> Ryan
>
> On Mon, Jun 3, 2019 at 12:46 PM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
>>
>> This is a GitLab wiki markup question.
>>
>> Suppose I want to have a bulleted list, in which a single item has some text, then some laid-out code, then more text.  I want the second blob of text to be indented as part of the bullet.
>>
>> Absent the laid-out code, indenting the second para 2 spaces seems to do it:
>>
>> * first bit of text
>>
>>
>>
>>   Second bit of text
>>
>> But if there is code in the middle, like this
>>
>> * first bit of text
>>
>> ```
>>
>> code
>>
>> ```
>>
>>   Second bit of text
>>
>> the second bit of text is not indented.
>>
>> Does anyone know how to achieve the indentation?
>>
>> Simon
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Tue Jun  4 20:53:21 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Jun 2019 20:53:21 +0000
Subject: Wiki markup
In-Reply-To: <CAO27hRpM6gYnu-Wf=JyqaWyidv0S27TOh8_OkNvheQsA8UJMGw@mail.gmail.com>
References: <DB7PR83MB02981B8EA28A5FF4C631DC6DAD140@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAO27hRpM6gYnu-Wf=JyqaWyidv0S27TOh8_OkNvheQsA8UJMGw@mail.gmail.com>
Message-ID: <DB7PR83MB0298DB6207EE377C5956C2DFAD150@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Ah yes!  You have to indent the triple-backticks by two spaces.  I never thought of that.  Thank you!

Duly noted in my gitlab lore https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj

Simon

From: Ryan Yates <fryguybob at gmail.com>
Sent: 03 June 2019 18:15
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: Wiki markup

Hi Simon,

I think you can just indent the code block to achieve this.

Ryan

On Mon, Jun 3, 2019 at 12:46 PM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
This is a GitLab wiki markup question.
Suppose I want to have a bulleted list, in which a single item has some text, then some laid-out code, then more text.  I want the second blob of text to be indented as part of the bullet.
Absent the laid-out code, indenting the second para 2 spaces seems to do it:

* first bit of text



  Second bit of text
But if there is code in the middle, like this

* first bit of text

```

code

```

  Second bit of text
the second bit of text is not indented.
Does anyone know how to achieve the indentation?
Simon
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<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%7C18c59b08b1914f0b4d4608d6e8470e7f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636951789237715881&sdata=JtGmVwUWxTKPmOEc52Vl%2F7%2BlF6byc%2FJhreQ5zqLhI%2Fg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190604/5765d497/attachment.html>

From nicolas.frisby at gmail.com  Wed Jun  5 03:02:21 2019
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Tue, 4 Jun 2019 20:02:21 -0700
Subject: should TcCanonical.rewriteEvidence preserve ctev_nosh?
In-Reply-To: <CADfHYo5+06+q9HXnCO6wtuKzo7nNTkaQf=5zF8MRZyun=5MRoA@mail.gmail.com>
References: <CADfHYo7CN6zDaRNUVSO7G25o5wtVS-SbvgsLkXotgJJQ--hwyQ@mail.gmail.com>
 <DB7PR83MB0298AD93427A43EE8C09C364AD1B0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CADfHYo5+06+q9HXnCO6wtuKzo7nNTkaQf=5zF8MRZyun=5MRoA@mail.gmail.com>
Message-ID: <CADfHYo762YnqV3kpRU9z5gwYGWykHxWs=zoyEQQcHT18OLK0Mw@mail.gmail.com>

I commented in the affirmative on your MR, Simon. Should I also re-assign
it back to you?

https://gitlab.haskell.org/ghc/ghc/merge_requests/1094

On Sun, Jun 2, 2019 at 12:15 PM Nicolas Frisby <nicolas.frisby at gmail.com>
wrote:

> Thank you for confirming, Simon.
>
> I opened https://gitlab.haskell.org/ghc/ghc/issues/16735
>
> On Sun, Jun 2, 2019 at 8:33 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> Nick
>>
>>
>>
>> That looks outright wrong to me.  Would you like to make a ticket for
>> it?  It should be easy to fix.
>>
>>
>>
>> I’m surprised it has not caused more trouble before now.
>>
>>
>>
>> Well spotted and well diagnosed!
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Nicolas
>> Frisby
>> *Sent:* 01 June 2019 04:24
>> *To:* ghc-devs at haskell.org
>> *Subject:* should TcCanonical.rewriteEvidence preserve ctev_nosh?
>>
>>
>>
>> A bit of context and then my question.
>>
>>
>>
>>
>> https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcCanonical.hs#L2226
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%2Ftypecheck%2FTcCanonical.hs%23L2226&data=02%7C01%7Csimonpj%40microsoft.com%7Cd90efcd1da6f4058c00c08d6e640c7c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949563239275987&sdata=F7dgkceI2512TafrGNP38xvWAv2%2F6HKQscRnU%2Bypbf8%3D&reserved=0>
>> declares `rewriteEvidence` with the comment that "rewriteEvidence old_ev
>> new_pred co  ... Returns a new_ev : new_pred, with same
>> wanted/given/derived flag as old_ev".
>>
>>
>>
>> However, the `CtWanted` case just immediately calls `newWanted`, which
>> ignores the incoming `ctev_nosh` flag and always uses `WDeriv`.
>>
>>
>> ```
>> rewriteEvidence ev@(CtWanted { ctev_dest = dest
>>
>>                              , ctev_loc = loc }) new_pred co
>>
>> = do { mb_new_ev <- newWanted loc new_pred
>> ```
>>
>>
>>
>> (This is true in 8.6.5 and also right now at
>> 6febc444c0abea6c033174aa0e813c950b9b2877.)
>>
>>
>>
>> Thus I'm seeing a [W] is become a [WD], which seems to contradict the
>> comment's "same flag" claim.
>>
>>
>>
>> MY QUESTION ======> Is this "WD unsplitting" the intended behavior? See
>> canonicalization tc-trace below.
>>
>>
>>
>> If it is intended, I'll probably write a follow-up question asking for
>> more advice. The constraint solver is looping unproductively because my
>> plugin keeps discarding the (re-)emitted [D] shadow as a tautology, then
>> the [W] "unsplits" during canonicalization (even though my plugin didn't
>> touch the [W]), this re-emits the same [D] (via a fundep), and so on.
>>
>>
>>
>> My continual disclaimer recently is that I'm seeing this behavior with my
>> in-development plugin activated, so it's entirely I'm pushing GHC into
>> unfamiliar waters or even just plain violating some invariants without
>> realizing it. But this trace looks rather isolated from plugins.
>>
>>
>>
>> Thanks! -Nick
>>
>>
>>
>> Here's a -ddump-tc-trace of a canonicalization that goes from [W] to [WD]
>> happen (with GHC 8.6.5):
>>
>> runStage canonicalization {
>>   workitem   =  [W] $dMonadFree_a35V {0}:: MonadFree
>>                                              ((fs_a2UF[sk:1] :- Const
>> e_a2UE[sk:1])
>>                                               :+ Const e_a2UE[sk:1])
>>                                              (Free fs_a2UF[sk:1])
>> (CDictCan)
>> flatten_args {
>>   (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]
>>   Free fs_a2UF[sk:1]
>> matchFamTcM
>>   Matching: (fs_a2UF[sk:1] :- Const e_a2UE[sk:1])
>>             :+ Const e_a2UE[sk:1]
>>   Match failed
>> matchFamTcM
>>   Matching: fs_a2UF[sk:1] :- Const e_a2UE[sk:1]
>>   Match failed
>> Unfilled tyvar fs_a2UF[sk:1]
>> Unfilled tyvar e_a2UE[sk:1]
>> flatten/flat-cache hit
>>   :- [* -> *, fs_a2UF[sk:1], Const e_a2UE[sk:1]]
>>   s_a35Z[fmv:1]
>> Unfilled tyvar s_a35Z[fmv:1]
>> Unfilled tyvar e_a2UE[sk:1]
>> matchFamTcM
>>   Matching: s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]
>>   Match failed
>> New coercion hole: co_a365
>> Emitting new coercion hole
>>   {co_a365} :: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
>>                GHC.Prim.~# s_a364[fmv:1]
>> extendFlatCache
>>   :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
>>   [WD]
>>   s_a364[fmv:1]
>> flatten/flat-cache miss
>>   :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]]
>>   s_a364[fmv:1]
>>   [WD] hole{co_a365} {0}:: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1])
>>                            GHC.Prim.~# s_a364[fmv:1]
>> Unfilled tyvar fs_a2UF[sk:1]
>> flatten }
>>   s_a364[fmv:1]
>>   Free fs_a2UF[sk:1]
>> Emitting new wanted
>>   $dMonadFree_a366 :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>>   arising from a use of ‘wrap’ at tests/ill-typed/T7.hs:77:14-17
>> addTcEvBind
>>   a2V1
>>   [W] $dMonadFree_a35V
>>     = $dMonadFree_a366
>>       `cast` ((MonadFree
>>                  (Sym {co_a365} ; ((:+)
>>                                      <* -> *>_N (Sym {co_a360}) <Const
>> e_a2UE[sk:1]>_N)_N)
>>                  <Free fs_a2UF[sk:1]>_N)_R
>>               :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>>                  ~R# MonadFree
>>                        ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const
>> e_a2UE[sk:1])
>>                        (Free fs_a2UF[sk:1]))
>> canClass
>>   [W] $dMonadFree_a35V {0}:: MonadFree
>>                                ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+
>> Const e_a2UE[sk:1])
>>                                (Free fs_a2UF[sk:1])
>>   MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1])
>>   ContinueWith [WD] $dMonadFree_a366 {0}:: MonadFree
>>                                              s_a364[fmv:1] (Free
>> fs_a2UF[sk:1])
>> end stage canonicalization }
>>
>>
>>
>>
>>
>>
>>
>> and later
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> try_fundeps
>>   [WD] $dMonadFree_a36h {0}:: MonadFree
>>                                 s_a36f[fmv:1] (Free fs_a2UF[sk:1])
>> (CDictCan)
>> emitFunDepDeriveds 1
>>   0
>>   [fs_a2UF[sk:1] ~ s_a36f[fmv:1]]
>>   False
>> Emitting new derived equality
>>   [D] _ {0}:: fs_a2UF[sk:1] GHC.Prim.~# s_a36f[fmv:1]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> and then my plugin discards that [D] as a tautological, and then the [W]
>> gets unsplit and the [D] comes back around etc
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190604/d6b7c5d2/attachment.html>

From vlatko.basic at gmail.com  Wed Jun  5 09:52:48 2019
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Wed, 5 Jun 2019 11:52:48 +0200
Subject: Strange behavior of "-with-rtsopts=-T
Message-ID: <7d8760cb-f8d7-522a-166d-d74616d9a45f@gmail.com>

Hello ghc-devs,

I wrote about this issue to haskell-cafe, but received no reply as of today, so 
I'm hoping I could get some answer(s) here.

I wrote a small Servant server that communicates with the same other server(s).


When compiled without "-with-rtsopts=-T", I see in 'gnome-system-monitor' that 
memory used by each server constantly growing.

I was investigating the issue, and found that it is (probably) not in my code, 
but in one http call (Servant client call to the same server).


When I compile it with "-with-rtsopts=-T", the memory is constant and steady.

Tested on Arch Linux with Stack LTS 13.14.


If any one wants to test this, here are the steps: (server is standalone and 
does not require any external services (like DB, Redis, etc) and uses just a few 
MBs of RAM.)

$ hg clone https://bitbucket.org/vlatkoB/poomas && cd poomas && stack build

## open your system monitor


## open two terminals in 'poomas' dir and in one run

$ srvb.sh 5

## and in the other #

$ srvb.sh 6

## (5 and 6 represent port number added to 3000, i.e. 3005 and 3006)

## Notice that memory is steady, around 6 MB on my machine.


## In 'server/package.yaml' comment out the line 139 (#-with-rtsopts=-T)

$ stack build --force-dirty

## start those two servers again and see memory usage growing.


Can anyone shed some light what could be happening here?


Best regards,

vlatko


From omeragacan at gmail.com  Thu Jun  6 10:22:40 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Thu, 6 Jun 2019 13:22:40 +0300
Subject: Strange behavior of "-with-rtsopts=-T
In-Reply-To: <7d8760cb-f8d7-522a-166d-d74616d9a45f@gmail.com>
References: <7d8760cb-f8d7-522a-166d-d74616d9a45f@gmail.com>
Message-ID: <CAMQQO3kj74Rijbom1we1Q1iUUkTRs=zCoqV7aw5z94kZjYC26w@mail.gmail.com>

Hi Vlatko,

Unless this is a side effect of calling getrusage() (perhaps it causes the OS to
update stats) I don't see how this is possible.

Your reproducer seems to require postgres so I'm unable to run it. If you can
provide a version that doesn't need postgres I can take a look.

Ömer

Vlatko Basic <vlatko.basic at gmail.com>, 5 Haz 2019 Çar, 12:53 tarihinde
şunu yazdı:
>
> Hello ghc-devs,
>
> I wrote about this issue to haskell-cafe, but received no reply as of today, so
> I'm hoping I could get some answer(s) here.
>
> I wrote a small Servant server that communicates with the same other server(s).
>
>
> When compiled without "-with-rtsopts=-T", I see in 'gnome-system-monitor' that
> memory used by each server constantly growing.
>
> I was investigating the issue, and found that it is (probably) not in my code,
> but in one http call (Servant client call to the same server).
>
>
> When I compile it with "-with-rtsopts=-T", the memory is constant and steady.
>
> Tested on Arch Linux with Stack LTS 13.14.
>
>
> If any one wants to test this, here are the steps: (server is standalone and
> does not require any external services (like DB, Redis, etc) and uses just a few
> MBs of RAM.)
>
> $ hg clone https://bitbucket.org/vlatkoB/poomas && cd poomas && stack build
>
> ## open your system monitor
>
>
> ## open two terminals in 'poomas' dir and in one run
>
> $ srvb.sh 5
>
> ## and in the other #
>
> $ srvb.sh 6
>
> ## (5 and 6 represent port number added to 3000, i.e. 3005 and 3006)
>
> ## Notice that memory is steady, around 6 MB on my machine.
>
>
> ## In 'server/package.yaml' comment out the line 139 (#-with-rtsopts=-T)
>
> $ stack build --force-dirty
>
> ## start those two servers again and see memory usage growing.
>
>
> Can anyone shed some light what could be happening here?
>
>
> Best regards,
>
> vlatko
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From matthewtpickering at gmail.com  Thu Jun  6 15:01:10 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 6 Jun 2019 16:01:10 +0100
Subject: Zurihac 2019 - Heap Profiling Projects
Message-ID: <CALuQ0m9pzZA6yUrOwGdM4_zPn_+Np4A8ikEbX9VTzddPvQidqw@mail.gmail.com>

Hi all,

I plan to do some work on the heap profiler during Zurihac this year.
I've written down quite a long list of possible projects if anyone
else wants to work on this with me. They are split into two
categories.

1. Improving my replacement for hp2ps/hp2pretty which parses and
renders eventlogs into an interactive HTML page.
2. General improvements to the heap profiler.

https://gitlab.haskell.org/ghc/ghc/wikis/Zurihac-2019-Profiler-Ideas

Feel free to add your own suggestions, as long as they are backed up
by a ticket.

Cheers,

Matt

From rae at richarde.dev  Thu Jun  6 19:33:59 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 6 Jun 2019 15:33:59 -0400
Subject: reviewing on GitLab
Message-ID: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>

Hi all,

I've just reviewed !364, and it was a painful experience. Perhaps documenting why will help spur more UI innovations.

- My review was in response to several of the author's in-line comments, which themselves were in response to previous in-line comments. This has to be a common scenario.

- The *only* place I could get a simple listing of all the new comments was in my notification email. Neither the Discussion tab nor the Changes tab on GitLab allow me to collect recent comments, as they new comments are placed directly below the old comments, each of which started at different points in time.

- The Discussions tab has all the comments somewhere. But for each comment, I had to search (with Ctrl+F) on the page to find the corresponding comment trail, so I could get context. The order on the Discussions tab was unrelated to the order in my email.

- Actually, not all comments were on the Discussions page, because the commit author had *resolved* a discussion. In this case, though, I still wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I could find the comment trail and unresolve it.

- The Changes page has much more code context than the Discussions page. So I had that open, too, so I could scroll through the code. Not all the comments appeared on the Changes page, because the most interesting, most important files are always hidden by default. Even after expanding the relevant files, the comment trails did not always appear. Perhaps 30 seconds wasn't enough waiting.

- All this means that this was my workflow:
  1. Scroll through my notification email to see the author's next comment.
  2. Ctrl+F with the text of that comment to find it on the Discussion tab. (Ctrl+F for "resolved" if the first search fails.)
  3. If necessary, then use the line numbers and source file names from the Discussions tab to find the the relevant code in the Changes tab... which were often offset by a few lines, as things churn.

I needed three windows open to complete a fairly simple review!

I believe this is easy to fix: make the Discussions tab *chronological*. And have a link from the comment on the Discussions page to the Changes page that warps you to just the right spot in the code, with the full commentary context. (Right now, the link from the Discussions page just brings you to the file in the Changes page, not the line.)

I know this isn't the first time we've suggested this or complained, but I'm not aware of progress (or even "it's on our queue") from GitLab. Has that happened? Is there a way to prioritize this? This review process is really a drag!

Many thanks,
Richard

From simonpj at microsoft.com  Thu Jun  6 22:01:32 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Jun 2019 22:01:32 +0000
Subject: reviewing on GitLab
In-Reply-To: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
References: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
Message-ID: <DB7PR83MB0298B9FF878799E87C91C127AD170@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I agree.  It's frustrating.

I spent quite a bit of effort distilling ideas to help make GitLab better here: https://docs.google.com/document/d/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1QJQ/edit?usp=sharing

We shared those ideas with them, and I believe they promised to think about them.  I think would be reasonable to ask them politely whether they see any merit in them, whether there is any chance they might get implemented, and whether they would be willing to engage in a dialogue with us about them.

Issue #1 is by far the most important.

Richard: you might want to elaborate the document with any new problems you have now uncovered.

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
| Eisenberg
| Sent: 06 June 2019 20:34
| To: Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>
| Subject: reviewing on GitLab
| 
| Hi all,
| 
| I've just reviewed !364, and it was a painful experience. Perhaps
| documenting why will help spur more UI innovations.
| 
| - My review was in response to several of the author's in-line comments,
| which themselves were in response to previous in-line comments. This has
| to be a common scenario.
| 
| - The *only* place I could get a simple listing of all the new comments
| was in my notification email. Neither the Discussion tab nor the Changes
| tab on GitLab allow me to collect recent comments, as they new comments
| are placed directly below the old comments, each of which started at
| different points in time.
| 
| - The Discussions tab has all the comments somewhere. But for each
| comment, I had to search (with Ctrl+F) on the page to find the
| corresponding comment trail, so I could get context. The order on the
| Discussions tab was unrelated to the order in my email.
| 
| - Actually, not all comments were on the Discussions page, because the
| commit author had *resolved* a discussion. In this case, though, I still
| wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I
| could find the comment trail and unresolve it.
| 
| - The Changes page has much more code context than the Discussions page.
| So I had that open, too, so I could scroll through the code. Not all the
| comments appeared on the Changes page, because the most interesting, most
| important files are always hidden by default. Even after expanding the
| relevant files, the comment trails did not always appear. Perhaps 30
| seconds wasn't enough waiting.
| 
| - All this means that this was my workflow:
|   1. Scroll through my notification email to see the author's next
| comment.
|   2. Ctrl+F with the text of that comment to find it on the Discussion
| tab. (Ctrl+F for "resolved" if the first search fails.)
|   3. If necessary, then use the line numbers and source file names from
| the Discussions tab to find the the relevant code in the Changes tab...
| which were often offset by a few lines, as things churn.
| 
| I needed three windows open to complete a fairly simple review!
| 
| I believe this is easy to fix: make the Discussions tab *chronological*.
| And have a link from the comment on the Discussions page to the Changes
| page that warps you to just the right spot in the code, with the full
| commentary context. (Right now, the link from the Discussions page just
| brings you to the file in the Changes page, not the line.)
| 
| I know this isn't the first time we've suggested this or complained, but
| I'm not aware of progress (or even "it's on our queue") from GitLab. Has
| that happened? Is there a way to prioritize this? This review process is
| really a drag!
| 
| Many thanks,
| Richard
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at richarde.dev  Thu Jun  6 22:42:15 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 6 Jun 2019 18:42:15 -0400
Subject: reviewing on GitLab
In-Reply-To: <DB7PR83MB0298B9FF878799E87C91C127AD170@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
 <DB7PR83MB0298B9FF878799E87C91C127AD170@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <AD29BC48-E64F-45B3-BC27-5C285FB57F30@richarde.dev>

Very helpfully, that document now has GitLab issue numbers. I just pinged the one about the discussions tab.

One issue in that document that doesn't have a GitLab Issue number is "Issue 5: Prioritising numbers". Ben (or others who have interfaced with GL central): has this been reported upstream? I'm reluctant to do so without the context of our collaboration.

Thanks,
Richard

> On Jun 6, 2019, at 6:01 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I agree.  It's frustrating.
> 
> I spent quite a bit of effort distilling ideas to help make GitLab better here: https://docs.google.com/document/d/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1QJQ/edit?usp=sharing
> 
> We shared those ideas with them, and I believe they promised to think about them.  I think would be reasonable to ask them politely whether they see any merit in them, whether there is any chance they might get implemented, and whether they would be willing to engage in a dialogue with us about them.
> 
> Issue #1 is by far the most important.
> 
> Richard: you might want to elaborate the document with any new problems you have now uncovered.
> 
> Simon
> 
> | -----Original Message-----
> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
> | Eisenberg
> | Sent: 06 June 2019 20:34
> | To: Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>
> | Subject: reviewing on GitLab
> | 
> | Hi all,
> | 
> | I've just reviewed !364, and it was a painful experience. Perhaps
> | documenting why will help spur more UI innovations.
> | 
> | - My review was in response to several of the author's in-line comments,
> | which themselves were in response to previous in-line comments. This has
> | to be a common scenario.
> | 
> | - The *only* place I could get a simple listing of all the new comments
> | was in my notification email. Neither the Discussion tab nor the Changes
> | tab on GitLab allow me to collect recent comments, as they new comments
> | are placed directly below the old comments, each of which started at
> | different points in time.
> | 
> | - The Discussions tab has all the comments somewhere. But for each
> | comment, I had to search (with Ctrl+F) on the page to find the
> | corresponding comment trail, so I could get context. The order on the
> | Discussions tab was unrelated to the order in my email.
> | 
> | - Actually, not all comments were on the Discussions page, because the
> | commit author had *resolved* a discussion. In this case, though, I still
> | wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I
> | could find the comment trail and unresolve it.
> | 
> | - The Changes page has much more code context than the Discussions page.
> | So I had that open, too, so I could scroll through the code. Not all the
> | comments appeared on the Changes page, because the most interesting, most
> | important files are always hidden by default. Even after expanding the
> | relevant files, the comment trails did not always appear. Perhaps 30
> | seconds wasn't enough waiting.
> | 
> | - All this means that this was my workflow:
> |   1. Scroll through my notification email to see the author's next
> | comment.
> |   2. Ctrl+F with the text of that comment to find it on the Discussion
> | tab. (Ctrl+F for "resolved" if the first search fails.)
> |   3. If necessary, then use the line numbers and source file names from
> | the Discussions tab to find the the relevant code in the Changes tab...
> | which were often offset by a few lines, as things churn.
> | 
> | I needed three windows open to complete a fairly simple review!
> | 
> | I believe this is easy to fix: make the Discussions tab *chronological*.
> | And have a link from the comment on the Discussions page to the Changes
> | page that warps you to just the right spot in the code, with the full
> | commentary context. (Right now, the link from the Discussions page just
> | brings you to the file in the Changes page, not the line.)
> | 
> | I know this isn't the first time we've suggested this or complained, but
> | I'm not aware of progress (or even "it's on our queue") from GitLab. Has
> | that happened? Is there a way to prioritize this? This review process is
> | really a drag!
> | 
> | Many thanks,
> | Richard
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at well-typed.com  Fri Jun  7 00:56:14 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 06 Jun 2019 20:56:14 -0400
Subject: reviewing on GitLab
In-Reply-To: <AD29BC48-E64F-45B3-BC27-5C285FB57F30@richarde.dev>
References: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
 <DB7PR83MB0298B9FF878799E87C91C127AD170@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <AD29BC48-E64F-45B3-BC27-5C285FB57F30@richarde.dev>
Message-ID: <87blza1adv.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> writes:

> Very helpfully, that document now has GitLab issue numbers. I just
> pinged the one about the discussions tab.
>
> One issue in that document that doesn't have a GitLab Issue number is
> "Issue 5: Prioritising numbers". Ben (or others who have interfaced
> with GL central): has this been reported upstream? I'm reluctant to do
> so without the context of our collaboration.
>
Hi Richard,

Alp dug up a few previous issues requesting a number-centric UI (#21712
and #1734; references added to document). For better or worse, both have
been closed, one merge request changing the behavior ended in a revert,
and at least some GitLab contributors believe that titles make for a
better identifier. Regardless, I think there is a strong argument to be
made that this should at very least be configurable; we can try to make
this argument.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190606/8255b99b/attachment.sig>

From ben at well-typed.com  Fri Jun  7 01:28:00 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 06 Jun 2019 21:28:00 -0400
Subject: reviewing on GitLab
In-Reply-To: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
References: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
Message-ID: <878sue18x1.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> writes:

> Hi all,
>
> I've just reviewed !364, and it was a painful experience. Perhaps
> documenting why will help spur more UI innovations.
>
Indeed. Thanks for making sure these issues don't fall by the wayside.

> I believe this is easy to fix: make the Discussions tab
> *chronological*. And have a link from the comment on the Discussions
> page to the Changes page that warps you to just the right spot in the
> code, with the full commentary context. (Right now, the link from the
> Discussions page just brings you to the file in the Changes page, not
> the line.)
>
> I know this isn't the first time we've suggested this or complained,
> but I'm not aware of progress (or even "it's on our queue") from
> GitLab. Has that happened? Is there a way to prioritize this? This
> review process is really a drag!
>
Simon and I had a discussion with James Ramsey, a project manager with
GitLab, around Simon's document a few months ago. They identified their
first priority as work on merge queue infrastructure (another request of
ours, although it's not on Simon's list); this work is tracked as
gitlab-ee#9186 and a version of it will be shipped in GitLab 12.0, next
month's release.

James made it clear that another of his priorities for this year was to
look at the current discussion interface and try to mitigate the sorts
of problems that we are encountering. Simon proposed that the situation
could be improved by presenting comments chronologically. James found
this to be an interesting suggestion and said he would add it to his
bucket of ideas.

With respect to timing: There were understandably no concrete timelines
given. James said that work on the discussion model would likely only
happen in the second half of the year (which we are now just entering).
Since then work on the merge train infrastructure has progressed a bit
more slower than expected, so I suspect things may happen a bit later
than expected. Moreover, neither gitlab-org&855 nor gitlab-ce#56481 have
milestones yet so I expect the timescale is at least on the order of
several months, unfortunately.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190606/90774cb1/attachment.sig>

From vlatko.basic at gmail.com  Fri Jun  7 07:48:17 2019
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Fri, 7 Jun 2019 09:48:17 +0200
Subject: Strange behavior of "-with-rtsopts=-T
In-Reply-To: <CAMQQO3kj74Rijbom1we1Q1iUUkTRs=zCoqV7aw5z94kZjYC26w@mail.gmail.com>
References: <7d8760cb-f8d7-522a-166d-d74616d9a45f@gmail.com>
 <CAMQQO3kj74Rijbom1we1Q1iUUkTRs=zCoqV7aw5z94kZjYC26w@mail.gmail.com>
Message-ID: <fc778850-1a2c-d39d-2c83-1ee5f9e8c17b@gmail.com>

Hi Ömer,

It doesn't require Postgres, I just haven't cleaned up the dependencies. My bad. :-(

I pushed the cleaned version.


However, noticed strange thing during testing of the cleaned package. There is 
no leak any more. And the problem is that I can't reproduce it, not even with 
previous commits.

Without "-T", it does use double+ the memory (12-14 MB) than with "-T" (<5 MB), 
which is strange, but the memory doesn't grow any more.

Will do more testing in the next few days. The only thing I can think of now is 
that I updated something in the environment.


So, unless you're curious, there's no need to waste your time. Thanks for the 
offer, though. :-)


br,

vlatko


On 06/06/2019 12:22, Ömer Sinan Ağacan wrote:
> Hi Vlatko,
>
> Unless this is a side effect of calling getrusage() (perhaps it causes the OS to
> update stats) I don't see how this is possible.
>
> Your reproducer seems to require postgres so I'm unable to run it. If you can
> provide a version that doesn't need postgres I can take a look.
>
> Ömer
>
> Vlatko Basic<vlatko.basic at gmail.com>, 5 Haz 2019 Çar, 12:53 tarihinde
> şunu yazdı:
>> Hello ghc-devs,
>>
>> I wrote about this issue to haskell-cafe, but received no reply as of today, so
>> I'm hoping I could get some answer(s) here.
>>
>> I wrote a small Servant server that communicates with the same other server(s).
>>
>>
>> When compiled without "-with-rtsopts=-T", I see in 'gnome-system-monitor' that
>> memory used by each server constantly growing.
>>
>> I was investigating the issue, and found that it is (probably) not in my code,
>> but in one http call (Servant client call to the same server).
>>
>>
>> When I compile it with "-with-rtsopts=-T", the memory is constant and steady.
>>
>> Tested on Arch Linux with Stack LTS 13.14.
>>
>>
>> If any one wants to test this, here are the steps: (server is standalone and
>> does not require any external services (like DB, Redis, etc) and uses just a few
>> MBs of RAM.)
>>
>> $ hg clonehttps://bitbucket.org/vlatkoB/poomas  && cd poomas && stack build
>>
>> ## open your system monitor
>>
>>
>> ## open two terminals in 'poomas' dir and in one run
>>
>> $ srvb.sh 5
>>
>> ## and in the other #
>>
>> $ srvb.sh 6
>>
>> ## (5 and 6 represent port number added to 3000, i.e. 3005 and 3006)
>>
>> ## Notice that memory is steady, around 6 MB on my machine.
>>
>>
>> ## In 'server/package.yaml' comment out the line 139 (#-with-rtsopts=-T)
>>
>> $ stack build --force-dirty
>>
>> ## start those two servers again and see memory usage growing.
>>
>>
>> Can anyone shed some light what could be happening here?
>>
>>
>> Best regards,
>>
>> vlatko
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at richarde.dev  Fri Jun  7 14:11:55 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 7 Jun 2019 10:11:55 -0400
Subject: reviewing on GitLab
In-Reply-To: <878sue18x1.fsf@smart-cactus.org>
References: <B90C7B95-FEEF-4075-A879-AB204E3A65B1@richarde.dev>
 <878sue18x1.fsf@smart-cactus.org>
Message-ID: <6454226B-4597-4C83-A882-1C18E3666C58@richarde.dev>

Thanks, Ben, for this summary. I am happy to wait for a resolution -- as long as there is some hope that waiting will not be in vain. This email indeed gives me this hope.

And, for the record, I agree that the merge-train support should be significantly higher priority. The whole merge scenario has caused much more trouble than a poor UI for reviewing.

Thanks!
Richard

> On Jun 6, 2019, at 9:28 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Simon and I had a discussion with James Ramsey, a project manager with
> GitLab, around Simon's document a few months ago. They identified their
> first priority as work on merge queue infrastructure (another request of
> ours, although it's not on Simon's list); this work is tracked as
> gitlab-ee#9186 and a version of it will be shipped in GitLab 12.0, next
> month's release.
> 
> James made it clear that another of his priorities for this year was to
> look at the current discussion interface and try to mitigate the sorts
> of problems that we are encountering. Simon proposed that the situation
> could be improved by presenting comments chronologically. James found
> this to be an interesting suggestion and said he would add it to his
> bucket of ideas.
> 
> With respect to timing: There were understandably no concrete timelines
> given. James said that work on the discussion model would likely only
> happen in the second half of the year (which we are now just entering).
> Since then work on the merge train infrastructure has progressed a bit
> more slower than expected, so I suspect things may happen a bit later
> than expected. Moreover, neither gitlab-org&855 nor gitlab-ce#56481 have
> milestones yet so I expect the timescale is at least on the order of
> several months, unfortunately.

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

From david.feuer at gmail.com  Fri Jun  7 17:36:41 2019
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 7 Jun 2019 13:36:41 -0400
Subject: Typed hole improvements
Message-ID: <CAMgWh9sYyCw8A9_eyXBgqk2Ty1SvgKa5BowLnndZsZ78wD4KPQ@mail.gmail.com>

I've been playing around with 8.6.3, and I've really been appreciating the
improvements in typed hole messages. Both the information about constraints
and the suggestions for filling the holes have proven valuable in heavily
typish programming. Thanks! One thing that's still not where I'd like it to
be is the equality constraint display. I recognize this is a Hard Problem.
But digging through something like

  x ~ C y z
  x ~ C y1 z2
  D p b ~ q z y1

to get b ~ y gets tiresome. Is there room for improvement here? If not, are
there any programs around using the GHC API to offer an interactive system
for such calculations? It'd be quite helpful when seeing such constraints
to be able to express special interest in a particular type variable, for
example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190607/38aed2c2/attachment.html>

From simonpj at microsoft.com  Fri Jun  7 18:25:59 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 7 Jun 2019 18:25:59 +0000
Subject: Typed hole improvements
In-Reply-To: <CAMgWh9sYyCw8A9_eyXBgqk2Ty1SvgKa5BowLnndZsZ78wD4KPQ@mail.gmail.com>
References: <CAMgWh9sYyCw8A9_eyXBgqk2Ty1SvgKa5BowLnndZsZ78wD4KPQ@mail.gmail.com>
Message-ID: <AM0PR83MB02898B52E37BDE0D0D51A239AD100@AM0PR83MB0289.EURPRD83.prod.outlook.com>

The constraint solver can certainly simplify this to get b ~ y.   Perhaps all that is needed is to call it?

David: a small reproducer would be helpful.

Mathias, yell if you need help.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of David Feuer
Sent: 07 June 2019 18:37
To: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs <ghc-devs at haskell.org>
Subject: Typed hole improvements

I've been playing around with 8.6.3, and I've really been appreciating the improvements in typed hole messages. Both the information about constraints and the suggestions for filling the holes have proven valuable in heavily typish programming. Thanks! One thing that's still not where I'd like it to be is the equality constraint display. I recognize this is a Hard Problem. But digging through something like

  x ~ C y z
  x ~ C y1 z2
  D p b ~ q z y1

to get b ~ y gets tiresome. Is there room for improvement here? If not, are there any programs around using the GHC API to offer an interactive system for such calculations? It'd be quite helpful when seeing such constraints to be able to express special interest in a particular type variable, for example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190607/6793dd89/attachment.html>

From hafnersimon at gmail.com  Tue Jun 11 02:11:04 2019
From: hafnersimon at gmail.com (Simon Hafner)
Date: Tue, 11 Jun 2019 04:11:04 +0200
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <87tvdemfb5.fsf@smart-cactus.org>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <87tvdemfb5.fsf@smart-cactus.org>
Message-ID: <CAOXyUO8RsK=Nef2X4BVWe_szjTs7tWCKpAQm5vb5D_B9Mgxw-Q@mail.gmail.com>

I have a ~ 30 minute talk which covers my GHC proposal
(NoToplevelFieldSelectors), as well as parts of the renamer. I could hold
that at any point, if there's still time slots over.

Am Di., 28. Mai 2019 um 23:37 Uhr schrieb Ben Gamari <ben at smart-cactus.org>:

> Andreas Herrmann <andreash87 at gmx.ch> writes:
>
> > Dear GHC devs,
> >
> I've been rather quiet on this since it's been unclear whether I will
> be able to make it to ZuriHac this year. While I would love to be there
> (and perhaps do some hiking after), at this point chances are
> unfortunately looking rather slim; it looks like I may have contracted
> Lyme disease so international traveling likely isn't a good idea in the
> next couple of months.
>
> I can, however, try to be around on IRC as festivities are underway.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190611/1f69a328/attachment.html>

From sven.tennie at gmail.com  Tue Jun 11 06:29:43 2019
From: sven.tennie at gmail.com (Sven Tennie)
Date: Tue, 11 Jun 2019 08:29:43 +0200
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CALuQ0m-19rFehq-UDM0ZCk8iH9ksaX=GHOvVqVHBTN85o+iBBA@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <CALuQ0m-19rFehq-UDM0ZCk8iH9ksaX=GHOvVqVHBTN85o+iBBA@mail.gmail.com>
Message-ID: <CALgrwrb1njgyb6XdUEhLB=_3ckL_j+OYSwYhViWta11J9nfK9Q@mail.gmail.com>

Hey Matthew,

Could you do me a big favor and record/document this session? Unfortunately
I won't make it to the ZuriHac, but I'm highly interested in improving my
GHC workflow.

Currently I'm working in a cycle of:

1. read code in haskell-code-explorer [1]
2. modify it in Emacs (currently only syntax highlighting, no type checking)
3. look at ghcid if the types match
4. goto 1 or use hadrian to build

I guess this may be improved by the haskell-ide-engine.

Of course would it be amazing, if all talks could be recorded.

BTW - If any of the other readers has a better setup, please share. I found
very little about IDE setup for GHC in the Wiki or Internet and the
"standard" dante or intero approaches don't seem to work, at least not out
of the box.

Best regards,

Sven

[1] - https://haskell-code-explorer.mfix.io/package/ghc-8.6.1/

Am Sa., 25. Mai 2019 um 13:08 Uhr schrieb Matthew Pickering <
matthewtpickering at gmail.com>:

> Andreas/Niklas,
>
> I can do a talk/demo of using tools such as `ghc-artefact-nix`,
> `haskell-ide-engine`, `ghcid`, GHC's debugger whilst working on GHC.
> Could you schedule in a 30 minute slot for that please if you think it
> would be of interest.
>
> Cheers,
>
> Matt
>
> On Tue, Apr 23, 2019 at 5:52 PM Andreas Herrmann <andreash87 at gmx.ch>
> wrote:
> >
> > Dear GHC devs,
> >
> > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to
> foster contributions to GHC and teach newcomers how to participate in GHC's
> development. It was a great success last year, and we hope it will be a
> great success this year as well.
> >
> > For that we need your help: We would like to invite you to organize a
> session in the GHC track. This could be in form of a presentation, a
> workshop, or a hack session with topics centered around GHC.
> >
> > For some inspiration, these are the subjects from last year's track:
> > - Continuous Integration / DevOps, by Manual Chakravarty
> > - PrimOps / PrimTypes, by Michal Terepeta
> > - Performance Regression Tests, by Niklas Hambüchen
> > - Newcomers Tutorial, by Andreas Herrmann
> >
> > Other possible subjects could be around:
> > - Improving documentation
> > - Extending GHC's test-suite
> > - General GHC development workflows
> > - The inner workings of some aspect of GHC
> >
> > Aside from preparing a session, we are also looking for volunteers to be
> around as GHC mentors during hack sessions to help out newcomers.
> >
> > Please let us know if you'd be interested in leading a session, or being
> a mentor, or helping out with this track in any other way. You can contact
> either Niklas or myself, on this list or by private message.
> >
> > Best,
> > Niklas and Andreas
> > ZuriHac 2019 GHC track coordinators
> >
> > [1]: https://zfoh.ch/zurihac2019/
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190611/90dcd213/attachment.html>

From matthewtpickering at gmail.com  Tue Jun 11 07:17:55 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 11 Jun 2019 08:17:55 +0100
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CALgrwrb1njgyb6XdUEhLB=_3ckL_j+OYSwYhViWta11J9nfK9Q@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <CALuQ0m-19rFehq-UDM0ZCk8iH9ksaX=GHOvVqVHBTN85o+iBBA@mail.gmail.com>
 <CALgrwrb1njgyb6XdUEhLB=_3ckL_j+OYSwYhViWta11J9nfK9Q@mail.gmail.com>
Message-ID: <CALuQ0m-2=qV_qyqk70cY5OXvy+Wa=QXp_FRvtwp1A-7+W6+rpQ@mail.gmail.com>

I am writing a blog post concurrently with preparing my talk so I will
post that afterwards.

I would have expected `dante` to work with the `./hadrian/ghci.sh`
target. What goes wrong there?

The haskell-ide-engine support lives on a branch, which you are
welcome to try, but comes with no guarantees. It is more than a proof
of concept but less than fully production ready.

Matt

On Tue, Jun 11, 2019 at 7:29 AM Sven Tennie <sven.tennie at gmail.com> wrote:
>
> Hey Matthew,
>
> Could you do me a big favor and record/document this session? Unfortunately I won't make it to the ZuriHac, but I'm highly interested in improving my GHC workflow.
>
> Currently I'm working in a cycle of:
>
> 1. read code in haskell-code-explorer [1]
> 2. modify it in Emacs (currently only syntax highlighting, no type checking)
> 3. look at ghcid if the types match
> 4. goto 1 or use hadrian to build
>
> I guess this may be improved by the haskell-ide-engine.
>
> Of course would it be amazing, if all talks could be recorded.
>
> BTW - If any of the other readers has a better setup, please share. I found very little about IDE setup for GHC in the Wiki or Internet and the "standard" dante or intero approaches don't seem to work, at least not out of the box.
>
> Best regards,
>
> Sven
>
> [1] - https://haskell-code-explorer.mfix.io/package/ghc-8.6.1/
>
> Am Sa., 25. Mai 2019 um 13:08 Uhr schrieb Matthew Pickering <matthewtpickering at gmail.com>:
>>
>> Andreas/Niklas,
>>
>> I can do a talk/demo of using tools such as `ghc-artefact-nix`,
>> `haskell-ide-engine`, `ghcid`, GHC's debugger whilst working on GHC.
>> Could you schedule in a 30 minute slot for that please if you think it
>> would be of interest.
>>
>> Cheers,
>>
>> Matt
>>
>> On Tue, Apr 23, 2019 at 5:52 PM Andreas Herrmann <andreash87 at gmx.ch> wrote:
>> >
>> > Dear GHC devs,
>> >
>> > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well.
>> >
>> > For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC.
>> >
>> > For some inspiration, these are the subjects from last year's track:
>> > - Continuous Integration / DevOps, by Manual Chakravarty
>> > - PrimOps / PrimTypes, by Michal Terepeta
>> > - Performance Regression Tests, by Niklas Hambüchen
>> > - Newcomers Tutorial, by Andreas Herrmann
>> >
>> > Other possible subjects could be around:
>> > - Improving documentation
>> > - Extending GHC's test-suite
>> > - General GHC development workflows
>> > - The inner workings of some aspect of GHC
>> >
>> > Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers.
>> >
>> > Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message.
>> >
>> > Best,
>> > Niklas and Andreas
>> > ZuriHac 2019 GHC track coordinators
>> >
>> > [1]: https://zfoh.ch/zurihac2019/
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From b at chreekat.net  Tue Jun 11 11:28:22 2019
From: b at chreekat.net (Bryan Richter)
Date: Tue, 11 Jun 2019 14:28:22 +0300
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CALuQ0m-2=qV_qyqk70cY5OXvy+Wa=QXp_FRvtwp1A-7+W6+rpQ@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <CALuQ0m-19rFehq-UDM0ZCk8iH9ksaX=GHOvVqVHBTN85o+iBBA@mail.gmail.com>
 <CALgrwrb1njgyb6XdUEhLB=_3ckL_j+OYSwYhViWta11J9nfK9Q@mail.gmail.com>
 <CALuQ0m-2=qV_qyqk70cY5OXvy+Wa=QXp_FRvtwp1A-7+W6+rpQ@mail.gmail.com>
Message-ID: <CAH9BU=zdP0Yn2mcoXTm6zZnks+p37vUtCr_-a054M68u44V9Lg@mail.gmail.com>

Re haskell-ide-engine: I've been meaning to try it out, so I'm interested
in making progress on that branch this weekend, if someone can show me the
ropes and suggest some goals.

On Tue, 11 Jun 2019, 10.18 Matthew Pickering, <matthewtpickering at gmail.com>
wrote:

> I am writing a blog post concurrently with preparing my talk so I will
> post that afterwards.
>
> I would have expected `dante` to work with the `./hadrian/ghci.sh`
> target. What goes wrong there?
>
> The haskell-ide-engine support lives on a branch, which you are
> welcome to try, but comes with no guarantees. It is more than a proof
> of concept but less than fully production ready.
>
> Matt
>
> On Tue, Jun 11, 2019 at 7:29 AM Sven Tennie <sven.tennie at gmail.com> wrote:
> >
> > Hey Matthew,
> >
> > Could you do me a big favor and record/document this session?
> Unfortunately I won't make it to the ZuriHac, but I'm highly interested in
> improving my GHC workflow.
> >
> > Currently I'm working in a cycle of:
> >
> > 1. read code in haskell-code-explorer [1]
> > 2. modify it in Emacs (currently only syntax highlighting, no type
> checking)
> > 3. look at ghcid if the types match
> > 4. goto 1 or use hadrian to build
> >
> > I guess this may be improved by the haskell-ide-engine.
> >
> > Of course would it be amazing, if all talks could be recorded.
> >
> > BTW - If any of the other readers has a better setup, please share. I
> found very little about IDE setup for GHC in the Wiki or Internet and the
> "standard" dante or intero approaches don't seem to work, at least not out
> of the box.
> >
> > Best regards,
> >
> > Sven
> >
> > [1] - https://haskell-code-explorer.mfix.io/package/ghc-8.6.1/
> >
> > Am Sa., 25. Mai 2019 um 13:08 Uhr schrieb Matthew Pickering <
> matthewtpickering at gmail.com>:
> >>
> >> Andreas/Niklas,
> >>
> >> I can do a talk/demo of using tools such as `ghc-artefact-nix`,
> >> `haskell-ide-engine`, `ghcid`, GHC's debugger whilst working on GHC.
> >> Could you schedule in a 30 minute slot for that please if you think it
> >> would be of interest.
> >>
> >> Cheers,
> >>
> >> Matt
> >>
> >> On Tue, Apr 23, 2019 at 5:52 PM Andreas Herrmann <andreash87 at gmx.ch>
> wrote:
> >> >
> >> > Dear GHC devs,
> >> >
> >> > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track
> to foster contributions to GHC and teach newcomers how to participate in
> GHC's development. It was a great success last year, and we hope it will be
> a great success this year as well.
> >> >
> >> > For that we need your help: We would like to invite you to organize a
> session in the GHC track. This could be in form of a presentation, a
> workshop, or a hack session with topics centered around GHC.
> >> >
> >> > For some inspiration, these are the subjects from last year's track:
> >> > - Continuous Integration / DevOps, by Manual Chakravarty
> >> > - PrimOps / PrimTypes, by Michal Terepeta
> >> > - Performance Regression Tests, by Niklas Hambüchen
> >> > - Newcomers Tutorial, by Andreas Herrmann
> >> >
> >> > Other possible subjects could be around:
> >> > - Improving documentation
> >> > - Extending GHC's test-suite
> >> > - General GHC development workflows
> >> > - The inner workings of some aspect of GHC
> >> >
> >> > Aside from preparing a session, we are also looking for volunteers to
> be around as GHC mentors during hack sessions to help out newcomers.
> >> >
> >> > Please let us know if you'd be interested in leading a session, or
> being a mentor, or helping out with this track in any other way. You can
> contact either Niklas or myself, on this list or by private message.
> >> >
> >> > Best,
> >> > Niklas and Andreas
> >> > ZuriHac 2019 GHC track coordinators
> >> >
> >> > [1]: https://zfoh.ch/zurihac2019/
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190611/7e28d2fc/attachment.html>

From shayne.fletcher at daml.com  Tue Jun 11 12:14:50 2019
From: shayne.fletcher at daml.com (Shayne Fletcher)
Date: Tue, 11 Jun 2019 08:14:50 -0400
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CAOXyUO8RsK=Nef2X4BVWe_szjTs7tWCKpAQm5vb5D_B9Mgxw-Q@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <87tvdemfb5.fsf@smart-cactus.org>
 <CAOXyUO8RsK=Nef2X4BVWe_szjTs7tWCKpAQm5vb5D_B9Mgxw-Q@mail.gmail.com>
Message-ID: <CAKe9RRHJ8pY5X_D8E73m7_sOdgVyzTNx3mEL4bK262tTXA7Zsg@mail.gmail.com>

On Mon, Jun 10, 2019 at 10:11 PM Simon Hafner <hafnersimon at gmail.com> wrote:

> I have a ~ 30 minute talk which covers my GHC proposal
> (NoToplevelFieldSelectors), as well as parts of the renamer. I could hold
> that at any point, if there's still time slots over.
>

That would be awesome. I sure hope there is!

-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

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

From ndmitchell at gmail.com  Wed Jun 12 20:16:47 2019
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed, 12 Jun 2019 22:16:47 +0200
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CAH9BU=zdP0Yn2mcoXTm6zZnks+p37vUtCr_-a054M68u44V9Lg@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <CALuQ0m-19rFehq-UDM0ZCk8iH9ksaX=GHOvVqVHBTN85o+iBBA@mail.gmail.com>
 <CALgrwrb1njgyb6XdUEhLB=_3ckL_j+OYSwYhViWta11J9nfK9Q@mail.gmail.com>
 <CALuQ0m-2=qV_qyqk70cY5OXvy+Wa=QXp_FRvtwp1A-7+W6+rpQ@mail.gmail.com>
 <CAH9BU=zdP0Yn2mcoXTm6zZnks+p37vUtCr_-a054M68u44V9Lg@mail.gmail.com>
Message-ID: <CAKcFpmJLLCMMvvg-YVXJCXFU4jgp8=ppR0sTS=r01chtphFWJQ@mail.gmail.com>

If you're interested in the Haskell IDE story we've organised a
specific room for that. I'm hoping Matthew will be able to spend some
time in there too.

Thanks, Neil

On Tue, Jun 11, 2019 at 1:29 PM Bryan Richter <b at chreekat.net> wrote:
>
> Re haskell-ide-engine: I've been meaning to try it out, so I'm interested in making progress on that branch this weekend, if someone can show me the ropes and suggest some goals.
>
> On Tue, 11 Jun 2019, 10.18 Matthew Pickering, <matthewtpickering at gmail.com> wrote:
>>
>> I am writing a blog post concurrently with preparing my talk so I will
>> post that afterwards.
>>
>> I would have expected `dante` to work with the `./hadrian/ghci.sh`
>> target. What goes wrong there?
>>
>> The haskell-ide-engine support lives on a branch, which you are
>> welcome to try, but comes with no guarantees. It is more than a proof
>> of concept but less than fully production ready.
>>
>> Matt
>>
>> On Tue, Jun 11, 2019 at 7:29 AM Sven Tennie <sven.tennie at gmail.com> wrote:
>> >
>> > Hey Matthew,
>> >
>> > Could you do me a big favor and record/document this session? Unfortunately I won't make it to the ZuriHac, but I'm highly interested in improving my GHC workflow.
>> >
>> > Currently I'm working in a cycle of:
>> >
>> > 1. read code in haskell-code-explorer [1]
>> > 2. modify it in Emacs (currently only syntax highlighting, no type checking)
>> > 3. look at ghcid if the types match
>> > 4. goto 1 or use hadrian to build
>> >
>> > I guess this may be improved by the haskell-ide-engine.
>> >
>> > Of course would it be amazing, if all talks could be recorded.
>> >
>> > BTW - If any of the other readers has a better setup, please share. I found very little about IDE setup for GHC in the Wiki or Internet and the "standard" dante or intero approaches don't seem to work, at least not out of the box.
>> >
>> > Best regards,
>> >
>> > Sven
>> >
>> > [1] - https://haskell-code-explorer.mfix.io/package/ghc-8.6.1/
>> >
>> > Am Sa., 25. Mai 2019 um 13:08 Uhr schrieb Matthew Pickering <matthewtpickering at gmail.com>:
>> >>
>> >> Andreas/Niklas,
>> >>
>> >> I can do a talk/demo of using tools such as `ghc-artefact-nix`,
>> >> `haskell-ide-engine`, `ghcid`, GHC's debugger whilst working on GHC.
>> >> Could you schedule in a 30 minute slot for that please if you think it
>> >> would be of interest.
>> >>
>> >> Cheers,
>> >>
>> >> Matt
>> >>
>> >> On Tue, Apr 23, 2019 at 5:52 PM Andreas Herrmann <andreash87 at gmx.ch> wrote:
>> >> >
>> >> > Dear GHC devs,
>> >> >
>> >> > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well.
>> >> >
>> >> > For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC.
>> >> >
>> >> > For some inspiration, these are the subjects from last year's track:
>> >> > - Continuous Integration / DevOps, by Manual Chakravarty
>> >> > - PrimOps / PrimTypes, by Michal Terepeta
>> >> > - Performance Regression Tests, by Niklas Hambüchen
>> >> > - Newcomers Tutorial, by Andreas Herrmann
>> >> >
>> >> > Other possible subjects could be around:
>> >> > - Improving documentation
>> >> > - Extending GHC's test-suite
>> >> > - General GHC development workflows
>> >> > - The inner workings of some aspect of GHC
>> >> >
>> >> > Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers.
>> >> >
>> >> > Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message.
>> >> >
>> >> > Best,
>> >> > Niklas and Andreas
>> >> > ZuriHac 2019 GHC track coordinators
>> >> >
>> >> > [1]: https://zfoh.ch/zurihac2019/
>> >> > _______________________________________________
>> >> > ghc-devs mailing list
>> >> > ghc-devs at haskell.org
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Wed Jun 12 20:20:32 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 12 Jun 2019 22:20:32 +0200
Subject: Request for Nominations to the GHC Steering Committee
Message-ID: <90af96bdb996b5ab7e826281cbb6a5b10653538b.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for two or three
new member.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

There is no shortage of people who are eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until June 23th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190612/2a96978a/attachment.sig>

From andreash87 at gmx.ch  Thu Jun 13 11:52:11 2019
From: andreash87 at gmx.ch (Andreas Herrmann)
Date: Thu, 13 Jun 2019 13:52:11 +0200
Subject: ZuriHac 2019 - GHC Track
In-Reply-To: <CAKe9RRHJ8pY5X_D8E73m7_sOdgVyzTNx3mEL4bK262tTXA7Zsg@mail.gmail.com>
References: <CA+ouDUgrmwo+SQtyzYdBpOrxo91745vYhE3zPyL-c=6YE6m9Qg@mail.gmail.com>
 <87tvdemfb5.fsf@smart-cactus.org>
 <CAOXyUO8RsK=Nef2X4BVWe_szjTs7tWCKpAQm5vb5D_B9Mgxw-Q@mail.gmail.com>
 <CAKe9RRHJ8pY5X_D8E73m7_sOdgVyzTNx3mEL4bK262tTXA7Zsg@mail.gmail.com>
Message-ID: <CA+ouDUjub46=hdNQ9QJqOiPNXhP_F_s+rVgr9v96L3OuNerK5g@mail.gmail.com>

Dear GHC devs,

I'm happy to announce that thanks to your help we will have five very
interesting talks at the GHC track at this year's ZuriHac. The sessions
will be held in the Aula and will be recorded. The schedule is available on
the ZuriHac website: https://zfoh.ch/zurihac2019/#ghc-track

Next to the talks we've also reserved the joined rooms 1.219 & 1.221 for
hacking on GHC. Whether you're interested in contributing to GHC or
learning more about its internals, whether you're experienced and happy to
share your knowledge or new to GHC and would like to learn from others,
you're welcome to join us in those rooms.

Join us in the #ghc channel on https://slack.zurihac.info/. We'll be
communicating updates regarding the GHC track on that channel. And you're
invited to discuss GHC related topics, ask questions, and provide answers
on that channel.

Best wishes and see you at ZuriHac,

Andreas

On Tue, 11 Jun 2019 at 14:14, Shayne Fletcher via ghc-devs <
ghc-devs at haskell.org> wrote:

>
>
> On Mon, Jun 10, 2019 at 10:11 PM Simon Hafner <hafnersimon at gmail.com>
> wrote:
>
>> I have a ~ 30 minute talk which covers my GHC proposal
>> (NoToplevelFieldSelectors), as well as parts of the renamer. I could hold
>> that at any point, if there's still time slots over.
>>
>
> That would be awesome. I sure hope there is!
>
> --
> *Shayne Fletcher*
> Language Engineer */* +1 917 699 7663
> *Digital Asset* <https://digitalasset.com/>, creators of *DAML
> <https://daml.com/>*
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190613/95cbe896/attachment.html>

From ben at well-typed.com  Sat Jun 15 19:35:54 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 15 Jun 2019 15:35:54 -0400
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
Message-ID: <874l4qzlny.fsf@smart-cactus.org>

Hello everyone,

The GHC team is pleased to announce the second and likely last alpha
release of GHC 8.8.1. The source distribution, binary distributions, and
documentation are available at

    https://downloads.haskell.org/~ghc/8.8.1-alpha2

A draft of the release notes is also available [1].

This release is the culmination of over 3000 commits by over one hundred
contributors and has several new features and numerous bug fixes
relative to GHC 8.6:

 * Profiling now works correctly on 64-bit Windows (although still may
   be problematic on 32-bit Windows due to platform limitations; see
   #15934)

 * A new code layout algorithm for amd64's native code generator

 * The introduction of a late lambda-lifting pass which may reduce
   allocations significantly for some programs.

 * Further work on Trees That Grow, enabling improved code re-use of the
   Haskell AST in tooling

 * More locations where users can write `forall` (GHC Proposal #0007)

 * Further work on the Hadrian build system

This release brings a number of fixes since alpha 1:

 * A number of linker fixes (#16779, #16784)

 * The process, binary, Cabal, time, terminfo libraries have all been
   bumped to their final release versions

 * A regression rendering TemplateHaskell unusable in cross-compiled
   configurations has been fixed (#16331)

 * A regression causing compiler panics on compilation of some programs
   has been fixed (#16449)

 * -Wmissing-home-modules now handles hs-boot files correctly (#16551)

 * A regression causing some programs to fail at runtime has been fixed
   (#16066)

Due to on-going work on our release and testing infrastructure this
cycle is proceeding at a pace significantly slower than expected.
However, we anticipate that this investment will allow us to release a
more reliable, easier-to-install compiler on the planned six-month
release cadence in the future.

As always, if anything looks amiss do let us know.

Happy compiling!

Cheers,

- Ben

[1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190615/fe24af76/attachment.sig>

From juhpetersen at gmail.com  Sun Jun 16 14:44:24 2019
From: juhpetersen at gmail.com (Jens Petersen)
Date: Sun, 16 Jun 2019 22:44:24 +0800
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <874l4qzlny.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
Message-ID: <CAEDGBqKUdh9jTa8ZKoP54SvXDmhqHE4xzTXGjRSN_5us-rUv-A@mail.gmail.com>

Hi Ben, thanks

I am not able to get
https://downloads.haskell.org/ghc/8.8.1-alpha2/ghc-8.8.0.20190613-src.tar.xz
somehow.

Jens

On Sun, 16 Jun 2019 at 03:36, Ben Gamari <ben at well-typed.com> wrote:
>
> Hello everyone,
>
> The GHC team is pleased to announce the second and likely last alpha
> release of GHC 8.8.1. The source distribution, binary distributions, and
> documentation are available at
>
>     https://downloads.haskell.org/~ghc/8.8.1-alpha2
>
> A draft of the release notes is also available [1].
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>    be problematic on 32-bit Windows due to platform limitations; see
>    #15934)
>
>  * A new code layout algorithm for amd64's native code generator
>
>  * The introduction of a late lambda-lifting pass which may reduce
>    allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>    Haskell AST in tooling
>
>  * More locations where users can write `forall` (GHC Proposal #0007)
>
>  * Further work on the Hadrian build system
>
> This release brings a number of fixes since alpha 1:
>
>  * A number of linker fixes (#16779, #16784)
>
>  * The process, binary, Cabal, time, terminfo libraries have all been
>    bumped to their final release versions
>
>  * A regression rendering TemplateHaskell unusable in cross-compiled
>    configurations has been fixed (#16331)
>
>  * A regression causing compiler panics on compilation of some programs
>    has been fixed (#16449)
>
>  * -Wmissing-home-modules now handles hs-boot files correctly (#16551)
>
>  * A regression causing some programs to fail at runtime has been fixed
>    (#16066)
>
> Due to on-going work on our release and testing infrastructure this
> cycle is proceeding at a pace significantly slower than expected.
> However, we anticipate that this investment will allow us to release a
> more reliable, easier-to-install compiler on the planned six-month
> release cadence in the future.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
> [1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Sun Jun 16 15:24:38 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 16 Jun 2019 11:24:38 -0400
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <CAEDGBqKUdh9jTa8ZKoP54SvXDmhqHE4xzTXGjRSN_5us-rUv-A@mail.gmail.com>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAEDGBqKUdh9jTa8ZKoP54SvXDmhqHE4xzTXGjRSN_5us-rUv-A@mail.gmail.com>
Message-ID: <87tvcpy2mn.fsf@smart-cactus.org>

Jens Petersen <juhpetersen at gmail.com> writes:

> Hi Ben, thanks
>
> I am not able to get
> https://downloads.haskell.org/ghc/8.8.1-alpha2/ghc-8.8.0.20190613-src.tar.xz
> somehow.
>
Sigh, it looks like this is yet another CDN issue. Our CDN will surely
be the death of me. I've added yet another flush rule so this should be
fixed.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190616/00df3eeb/attachment.sig>

From matthewtpickering at gmail.com  Mon Jun 17 10:24:16 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 17 Jun 2019 11:24:16 +0100
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <874l4qzlny.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
Message-ID: <CALuQ0m8dkOQS+KxQJHpy8Ljp9S52J91uYMzhqU4VsynT0JJA6g@mail.gmail.com>

There seems to be no debian8 bindist which is different from every
release at least back to ghc-8.0.1.

On Sat, Jun 15, 2019 at 8:36 PM Ben Gamari <ben at well-typed.com> wrote:
>
> Hello everyone,
>
> The GHC team is pleased to announce the second and likely last alpha
> release of GHC 8.8.1. The source distribution, binary distributions, and
> documentation are available at
>
>     https://downloads.haskell.org/~ghc/8.8.1-alpha2
>
> A draft of the release notes is also available [1].
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>    be problematic on 32-bit Windows due to platform limitations; see
>    #15934)
>
>  * A new code layout algorithm for amd64's native code generator
>
>  * The introduction of a late lambda-lifting pass which may reduce
>    allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>    Haskell AST in tooling
>
>  * More locations where users can write `forall` (GHC Proposal #0007)
>
>  * Further work on the Hadrian build system
>
> This release brings a number of fixes since alpha 1:
>
>  * A number of linker fixes (#16779, #16784)
>
>  * The process, binary, Cabal, time, terminfo libraries have all been
>    bumped to their final release versions
>
>  * A regression rendering TemplateHaskell unusable in cross-compiled
>    configurations has been fixed (#16331)
>
>  * A regression causing compiler panics on compilation of some programs
>    has been fixed (#16449)
>
>  * -Wmissing-home-modules now handles hs-boot files correctly (#16551)
>
>  * A regression causing some programs to fail at runtime has been fixed
>    (#16066)
>
> Due to on-going work on our release and testing infrastructure this
> cycle is proceeding at a pace significantly slower than expected.
> However, we anticipate that this investment will allow us to release a
> more reliable, easier-to-install compiler on the planned six-month
> release cadence in the future.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
> [1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Mon Jun 17 12:23:09 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 17 Jun 2019 08:23:09 -0400
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <CALuQ0m8dkOQS+KxQJHpy8Ljp9S52J91uYMzhqU4VsynT0JJA6g@mail.gmail.com>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CALuQ0m8dkOQS+KxQJHpy8Ljp9S52J91uYMzhqU4VsynT0JJA6g@mail.gmail.com>
Message-ID: <D706D157-26AC-48B6-BE4E-F7B2DDBEE1EC@well-typed.com>

That is true and this will be fixed for the release candidate. However Debian 8 is now no longer Debian's current stable release so I wasn't prioritizing this issue. If the lack of a Debian 8 distribution is preventing anyone from testing please let me know.

Cheers,

- Ben


On June 17, 2019 6:24:16 AM EDT, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>There seems to be no debian8 bindist which is different from every
>release at least back to ghc-8.0.1.
>
>On Sat, Jun 15, 2019 at 8:36 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> Hello everyone,
>>
>> The GHC team is pleased to announce the second and likely last alpha
>> release of GHC 8.8.1. The source distribution, binary distributions,
>and
>> documentation are available at
>>
>>     https://downloads.haskell.org/~ghc/8.8.1-alpha2
>>
>> A draft of the release notes is also available [1].
>>
>> This release is the culmination of over 3000 commits by over one
>hundred
>> contributors and has several new features and numerous bug fixes
>> relative to GHC 8.6:
>>
>>  * Profiling now works correctly on 64-bit Windows (although still
>may
>>    be problematic on 32-bit Windows due to platform limitations; see
>>    #15934)
>>
>>  * A new code layout algorithm for amd64's native code generator
>>
>>  * The introduction of a late lambda-lifting pass which may reduce
>>    allocations significantly for some programs.
>>
>>  * Further work on Trees That Grow, enabling improved code re-use of
>the
>>    Haskell AST in tooling
>>
>>  * More locations where users can write `forall` (GHC Proposal #0007)
>>
>>  * Further work on the Hadrian build system
>>
>> This release brings a number of fixes since alpha 1:
>>
>>  * A number of linker fixes (#16779, #16784)
>>
>>  * The process, binary, Cabal, time, terminfo libraries have all been
>>    bumped to their final release versions
>>
>>  * A regression rendering TemplateHaskell unusable in cross-compiled
>>    configurations has been fixed (#16331)
>>
>>  * A regression causing compiler panics on compilation of some
>programs
>>    has been fixed (#16449)
>>
>>  * -Wmissing-home-modules now handles hs-boot files correctly
>(#16551)
>>
>>  * A regression causing some programs to fail at runtime has been
>fixed
>>    (#16066)
>>
>> Due to on-going work on our release and testing infrastructure this
>> cycle is proceeding at a pace significantly slower than expected.
>> However, we anticipate that this investment will allow us to release
>a
>> more reliable, easier-to-install compiler on the planned six-month
>> release cadence in the future.
>>
>> As always, if anything looks amiss do let us know.
>>
>> Happy compiling!
>>
>> Cheers,
>>
>> - Ben
>>
>> [1]
>https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190617/a0a75ca1/attachment.html>

From karel.gardas at centrum.cz  Mon Jun 17 16:07:36 2019
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 17 Jun 2019 18:07:36 +0200
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <874l4qzlny.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
Message-ID: <5D07BAC8.3010307@centrum.cz>


Hi Ben,

On 06/15/19 09:35 PM, Ben Gamari wrote:
> Hello everyone,
>
> The GHC team is pleased to announce the second and likely last alpha
> release of GHC 8.8.1. The source distribution, binary distributions, and
> documentation are available at
>
>      https://downloads.haskell.org/~ghc/8.8.1-alpha2
>
> A draft of the release notes is also available [1].

No sure why, but fix for #13633 has not made into the 8.8 branch. Due to 
this testwsdeque fails from time to time on POWER. Tested on 
ppc64le/ubuntu 18.04. Bootstrapped with ghc 8.6.3.

Is there any chance you may cherrypick Peter's fix in merge request 445? 
Would be great since otherwise besides some profiling related tests 
failing the build looks fine on ppc64le.

Thanks!
Karel


From ben at well-typed.com  Tue Jun 18 13:42:08 2019
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 18 Jun 2019 09:42:08 -0400
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <5D07BAC8.3010307@centrum.cz>
References: <874l4qzlny.fsf@smart-cactus.org> <5D07BAC8.3010307@centrum.cz>
Message-ID: <87muifxb6d.fsf@smart-cactus.org>

Karel Gardas <karel.gardas at centrum.cz> writes:

> Hi Ben,
>
> On 06/15/19 09:35 PM, Ben Gamari wrote:
>> Hello everyone,
>>
>> The GHC team is pleased to announce the second and likely last alpha
>> release of GHC 8.8.1. The source distribution, binary distributions, and
>> documentation are available at
>>
>>      https://downloads.haskell.org/~ghc/8.8.1-alpha2
>>
>> A draft of the release notes is also available [1].
>
> No sure why, but fix for #13633 has not made into the 8.8 branch. Due to 
> this testwsdeque fails from time to time on POWER. Tested on 
> ppc64le/ubuntu 18.04. Bootstrapped with ghc 8.6.3.
>
> Is there any chance you may cherrypick Peter's fix in merge request 445? 
> Would be great since otherwise besides some profiling related tests 
> failing the build looks fine on ppc64le.
>
Thanks Karel! I've cherry-picked this and there will be an additional
set of memory ordering fixes [1] appearing in 8.8 as well.

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/1128/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190618/45697481/attachment.sig>

From mle+hs at mega-nerd.com  Fri Jun 21 02:46:25 2019
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Fri, 21 Jun 2019 12:46:25 +1000
Subject: libraries/array bad git hash?
Message-ID: <20190621124625.f1683d7c218fe148b810b7fd@mega-nerd.com>

Hi all,

I just tried to clone a new copy of the GHC sources and on pulling
the submodules i get:

    Fetched in submodule path 'libraries/array', but it did not contain
    58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that
    commit failed.

I suspect that someone updated to that hash without pushing their changes
to the public repo.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From ben at well-typed.com  Fri Jun 21 03:37:00 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 20 Jun 2019 23:37:00 -0400
Subject: libraries/array bad git hash?
In-Reply-To: <20190621124625.f1683d7c218fe148b810b7fd@mega-nerd.com>
References: <20190621124625.f1683d7c218fe148b810b7fd@mega-nerd.com>
Message-ID: <87ef3ny5gu.fsf@smart-cactus.org>

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Hi all,
>
> I just tried to clone a new copy of the GHC sources and on pulling
> the submodules i get:
>
>     Fetched in submodule path 'libraries/array', but it did not contain
>     58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that
>     commit failed.
>
> I suspect that someone updated to that hash without pushing their changes
> to the public repo.
>
Hi Erik,

From which repository are you trying to clone? I just cloned from the upstream GitLab
repository without any trouble. I suspect you are cloning from a
stale repository as 58a7ea hasn't been the array commit referred to by
GHC's master branch for months now.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190620/ad593c5d/attachment.sig>

From mle+hs at mega-nerd.com  Fri Jun 21 04:06:15 2019
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Fri, 21 Jun 2019 14:06:15 +1000
Subject: libraries/array bad git hash?
In-Reply-To: <87ef3ny5gu.fsf@smart-cactus.org>
References: <20190621124625.f1683d7c218fe148b810b7fd@mega-nerd.com>
 <87ef3ny5gu.fsf@smart-cactus.org>
Message-ID: <20190621140615.9dc19969052d1341364c3ea8@mega-nerd.com>

Ben Gamari wrote:

> From which repository are you trying to clone? I just cloned from the upstream GitLab
> repository without any trouble. I suspect you are cloning from a
> stale repository as 58a7ea hasn't been the array commit referred to by
> GHC's master branch for months now.

Yep, fixed by cloning from:

    https://gitlab.haskell.org/ghc/ghc

as per the documentation. Thanks Ben!

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From rsx at bluewin.ch  Fri Jun 21 16:55:19 2019
From: rsx at bluewin.ch (Roland Senn)
Date: Fri, 21 Jun 2019 18:55:19 +0200
Subject: Hadrian: Suddenly a full build fails with: Rules may not be recursive
Message-ID: <1561136119.1530.6.camel@bluewin.ch>

Hi,

Suddenly I'm unable to build! As usual, I did:

git pull upstream master --recurse-submodules=yes
git submodule update --init --recursive


$ hadrian/build.sh clean
Up to date
| Removing Hadrian files...
| Remove directory _build/stage0
| Remove directory _build/stage1
| Remove directory _build/stage2
| Remove directory _build/stage3
| Remove directory sdistprep
| Remove directory _build (after build completes)
| Done.

... + statistics

$ hadrian/build.sh -c --flavour=devel2 -j2
Up to date
| Running boot...
Error when running Shake build system:
  at action, called at src/Rules.hs:68:19 in main:Rules
  at apply1, called at
src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
pment.Shake.Internal.Rules.Oracle
* Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
os"))
  at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
main:Hadrian.Oracles.TextFile
* Depends on: hadrian/cfg/system.config
  at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
* Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
rts/rts.cabal
  at apply1, called at
src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
pment.Shake.Internal.Rules.Oracle
* Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
os"))
* Raised the exception:
Build system error - recursion detected:
  Key type:   OracleQ KeyValue
  Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
os"))
Rules may not be recursive


OS is Linux Debian 9 (x86_64)

Any ideas what's wrong??

Many thanks and kind regards
   Roland

From matthewtpickering at gmail.com  Fri Jun 21 16:58:05 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 21 Jun 2019 17:58:05 +0100
Subject: Hadrian: Suddenly a full build fails with: Rules may not be
 recursive
In-Reply-To: <1561136119.1530.6.camel@bluewin.ch>
References: <1561136119.1530.6.camel@bluewin.ch>
Message-ID: <CALuQ0m-vmM8yeCh6+trwAr+ekgs+58+XFTHLW_tS0VAcoPPokA@mail.gmail.com>

The -c flag is broken.

Run ./boot and ./configure manually and then it should work (without -c)

Cheers,

Matt

On Fri, Jun 21, 2019 at 5:55 PM Roland Senn <rsx at bluewin.ch> wrote:
>
> Hi,
>
> Suddenly I'm unable to build! As usual, I did:
>
> git pull upstream master --recurse-submodules=yes
> git submodule update --init --recursive
>
>
> $ hadrian/build.sh clean
> Up to date
> | Removing Hadrian files...
> | Remove directory _build/stage0
> | Remove directory _build/stage1
> | Remove directory _build/stage2
> | Remove directory _build/stage3
> | Remove directory sdistprep
> | Remove directory _build (after build completes)
> | Done.
>
> ... + statistics
>
> $ hadrian/build.sh -c --flavour=devel2 -j2
> Up to date
> | Running boot...
> Error when running Shake build system:
>   at action, called at src/Rules.hs:68:19 in main:Rules
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
>   at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
> main:Hadrian.Oracles.TextFile
> * Depends on: hadrian/cfg/system.config
>   at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
> * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
> rts/rts.cabal
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> * Raised the exception:
> Build system error - recursion detected:
>   Key type:   OracleQ KeyValue
>   Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> Rules may not be recursive
>
>
> OS is Linux Debian 9 (x86_64)
>
> Any ideas what's wrong??
>
> Many thanks and kind regards
>    Roland
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From allbery.b at gmail.com  Fri Jun 21 16:58:54 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 21 Jun 2019 12:58:54 -0400
Subject: Hadrian: Suddenly a full build fails with: Rules may not be
 recursive
In-Reply-To: <1561136119.1530.6.camel@bluewin.ch>
References: <1561136119.1530.6.camel@bluewin.ch>
Message-ID: <CAKFCL4Xj4rUXDJgjNBHis3Ht8QQjKQnf2_dEip0WbJ5UdajpmA@mail.gmail.com>

"-c" is a bad option that conflates configuration and build, and leads to
this when certain kinds of configuration changes happen and alter the build
rules that are already running. Stop using "-c" and reconfigure properly
(./boot etc.). Yes, it's "convenient", right up until this happens. And
eventually this *will* happen, because configuration should not be done via
build rules.

On Fri, Jun 21, 2019 at 12:55 PM Roland Senn <rsx at bluewin.ch> wrote:

> Hi,
>
> Suddenly I'm unable to build! As usual, I did:
>
> git pull upstream master --recurse-submodules=yes
> git submodule update --init --recursive
>
>
> $ hadrian/build.sh clean
> Up to date
> | Removing Hadrian files...
> | Remove directory _build/stage0
> | Remove directory _build/stage1
> | Remove directory _build/stage2
> | Remove directory _build/stage3
> | Remove directory sdistprep
> | Remove directory _build (after build completes)
> | Done.
>
> ... + statistics
>
> $ hadrian/build.sh -c --flavour=devel2 -j2
> Up to date
> | Running boot...
> Error when running Shake build system:
>   at action, called at src/Rules.hs:68:19 in main:Rules
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
>   at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
> main:Hadrian.Oracles.TextFile
> * Depends on: hadrian/cfg/system.config
>   at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
> * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
> rts/rts.cabal
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> * Raised the exception:
> Build system error - recursion detected:
>   Key type:   OracleQ KeyValue
>   Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> Rules may not be recursive
>
>
> OS is Linux Debian 9 (x86_64)
>
> Any ideas what's wrong??
>
> Many thanks and kind regards
>    Roland
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190621/5eefa812/attachment.html>

From shayne.fletcher at daml.com  Fri Jun 21 17:55:49 2019
From: shayne.fletcher at daml.com (Shayne Fletcher)
Date: Fri, 21 Jun 2019 13:55:49 -0400
Subject: Hadrian: Suddenly a full build fails with: Rules may not be
 recursive
In-Reply-To: <1561136119.1530.6.camel@bluewin.ch>
References: <1561136119.1530.6.camel@bluewin.ch>
Message-ID: <CAKe9RRHExio4uHuVfLwOHOSs+6y=KjYoe8Pk=yd520O69H3H+Q@mail.gmail.com>

I think this is because `--configure` is currently broken
https://gitlab.haskell.org/ghc/ghc/issues/16809. You can work around by
running bootstrap and configure manually for now.

On Fri, Jun 21, 2019 at 12:55 PM Roland Senn <rsx at bluewin.ch> wrote:

> Hi,
>
> Suddenly I'm unable to build! As usual, I did:
>
> git pull upstream master --recurse-submodules=yes
> git submodule update --init --recursive
>
>
> $ hadrian/build.sh clean
> Up to date
> | Removing Hadrian files...
> | Remove directory _build/stage0
> | Remove directory _build/stage1
> | Remove directory _build/stage2
> | Remove directory _build/stage3
> | Remove directory sdistprep
> | Remove directory _build (after build completes)
> | Done.
>
> ... + statistics
>
> $ hadrian/build.sh -c --flavour=devel2 -j2
> Up to date
> | Running boot...
> Error when running Shake build system:
>   at action, called at src/Rules.hs:68:19 in main:Rules
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
>   at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
> main:Hadrian.Oracles.TextFile
> * Depends on: hadrian/cfg/system.config
>   at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
> * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
> rts/rts.cabal
>   at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
> pment.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> * Raised the exception:
> Build system error - recursion detected:
>   Key type:   OracleQ KeyValue
>   Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
> os"))
> Rules may not be recursive
>
>
> OS is Linux Debian 9 (x86_64)
>
> Any ideas what's wrong??
>
> Many thanks and kind regards
>    Roland
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

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

From shayne.fletcher at daml.com  Fri Jun 21 17:56:37 2019
From: shayne.fletcher at daml.com (Shayne Fletcher)
Date: Fri, 21 Jun 2019 13:56:37 -0400
Subject: Hadrian: Suddenly a full build fails with: Rules may not be
 recursive
In-Reply-To: <CAKe9RRHExio4uHuVfLwOHOSs+6y=KjYoe8Pk=yd520O69H3H+Q@mail.gmail.com>
References: <1561136119.1530.6.camel@bluewin.ch>
 <CAKe9RRHExio4uHuVfLwOHOSs+6y=KjYoe8Pk=yd520O69H3H+Q@mail.gmail.com>
Message-ID: <CAKe9RRE7kfFrL9oYqZyj2SW1eko0iOVSbQoYK9F1+qwtyAJGPw@mail.gmail.com>

Sorry @Matthew Pickering <matthewtpickering at gmail.com>. Fired off my
response before I saw yours!

On Fri, Jun 21, 2019 at 1:55 PM Shayne Fletcher <shayne.fletcher at daml.com>
wrote:

> I think this is because `--configure` is currently broken
> https://gitlab.haskell.org/ghc/ghc/issues/16809. You can work around by
> running bootstrap and configure manually for now.
>
> On Fri, Jun 21, 2019 at 12:55 PM Roland Senn <rsx at bluewin.ch> wrote:
>
>> Hi,
>>
>> Suddenly I'm unable to build! As usual, I did:
>>
>> git pull upstream master --recurse-submodules=yes
>> git submodule update --init --recursive
>>
>>
>> $ hadrian/build.sh clean
>> Up to date
>> | Removing Hadrian files...
>> | Remove directory _build/stage0
>> | Remove directory _build/stage1
>> | Remove directory _build/stage2
>> | Remove directory _build/stage3
>> | Remove directory sdistprep
>> | Remove directory _build (after build completes)
>> | Done.
>>
>> ... + statistics
>>
>> $ hadrian/build.sh -c --flavour=devel2 -j2
>> Up to date
>> | Running boot...
>> Error when running Shake build system:
>>   at action, called at src/Rules.hs:68:19 in main:Rules
>>   at apply1, called at
>> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
>> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
>> pment.Shake.Internal.Rules.Oracle
>> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
>> os"))
>>   at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in
>> main:Hadrian.Oracles.TextFile
>> * Depends on: hadrian/cfg/system.config
>>   at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure
>> * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal
>> rts/rts.cabal
>>   at apply1, called at
>> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2-
>> fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo
>> pment.Shake.Internal.Rules.Oracle
>> * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host-
>> os"))
>> * Raised the exception:
>> Build system error - recursion detected:
>>   Key type:   OracleQ KeyValue
>>   Key value:  OracleQ (KeyValue ("hadrian/cfg/system.config","host-
>> os"))
>> Rules may not be recursive
>>
>>
>> OS is Linux Debian 9 (x86_64)
>>
>> Any ideas what's wrong??
>>
>> Many thanks and kind regards
>>    Roland
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> --
> *Shayne Fletcher*
> Language Engineer */* +1 917 699 7663
> *Digital Asset* <https://digitalasset.com/>, creators of *DAML
> <https://daml.com/>*
>


-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

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

From george.colpitts at gmail.com  Fri Jun 21 21:10:19 2019
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 21 Jun 2019 18:10:19 -0300
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <874l4qzlny.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
Message-ID: <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>

Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes.

Cheers
George


On Sat, Jun 15, 2019 at 4:36 PM Ben Gamari <ben at well-typed.com> wrote:

> Hello everyone,
>
> The GHC team is pleased to announce the second and likely last alpha
> release of GHC 8.8.1. The source distribution, binary distributions, and
> documentation are available at
>
>     https://downloads.haskell.org/~ghc/8.8.1-alpha2
>
> A draft of the release notes is also available [1].
>
> This release is the culmination of over 3000 commits by over one hundred
> contributors and has several new features and numerous bug fixes
> relative to GHC 8.6:
>
>  * Profiling now works correctly on 64-bit Windows (although still may
>    be problematic on 32-bit Windows due to platform limitations; see
>    #15934)
>
>  * A new code layout algorithm for amd64's native code generator
>
>  * The introduction of a late lambda-lifting pass which may reduce
>    allocations significantly for some programs.
>
>  * Further work on Trees That Grow, enabling improved code re-use of the
>    Haskell AST in tooling
>
>  * More locations where users can write `forall` (GHC Proposal #0007)
>
>  * Further work on the Hadrian build system
>
> This release brings a number of fixes since alpha 1:
>
>  * A number of linker fixes (#16779, #16784)
>
>  * The process, binary, Cabal, time, terminfo libraries have all been
>    bumped to their final release versions
>
>  * A regression rendering TemplateHaskell unusable in cross-compiled
>    configurations has been fixed (#16331)
>
>  * A regression causing compiler panics on compilation of some programs
>    has been fixed (#16449)
>
>  * -Wmissing-home-modules now handles hs-boot files correctly (#16551)
>
>  * A regression causing some programs to fail at runtime has been fixed
>    (#16066)
>
> Due to on-going work on our release and testing infrastructure this
> cycle is proceeding at a pace significantly slower than expected.
> However, we anticipate that this investment will allow us to release a
> more reliable, easier-to-install compiler on the planned six-month
> release cadence in the future.
>
> As always, if anything looks amiss do let us know.
>
> Happy compiling!
>
> Cheers,
>
> - Ben
>
> [1]
> https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-notes.html
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190621/caa7f545/attachment.html>

From ml at stefansf.de  Sat Jun 22 09:23:06 2019
From: ml at stefansf.de (Stefan Schulze Frielinghaus)
Date: Sat, 22 Jun 2019 11:23:06 +0200
Subject: StgRun and reserved C stack space
Message-ID: <20190622092306.GA17249@localhost.localdomain>

Hi all,

I'm trying to understand how StgRun/StgReturn are supposed to be implemented.
My current understanding is that StgRun is called from C land in order to save
all callee-saved registers, allocate some stack space, and then finally jump to
an STG function.  StgReturn is the counterpart of StgRun and is called from STG
land in order to restore all callee-saved registers, free the previously
allocated stack space, and finally return to C land.

Assuming that my intuition is correct I still have some concerns regarding the
stack space which is allocated by StgRun.  StgRun allocates
RESERVED_C_STACK_BYTES many bytes on the C stack.  However, I cannot see how an
STG function is supposed to access this reserved area since no pointer is
derived or whatsoever.  Does an STG function make use of the C stack pointer
and assume that the reserved area is at the very bottom of the stack?

Lets make an example.  Assume the C ABI demands that every function
allocates a Register Save Area (RSA for short) at the bottom of a stack
frame which may be used by a subsequent C function.  That means a caller
allocates some stack space for its callee.  This area must be below the
local variable and parameter area which means it is at the very bottom
of a stack frame.  A C stack frame then looks as follows:

      .                     .
      .                     .
      | previous frame      |
      +---------------------+
      | local variables     |
      +---------------------+
      | parameter area      |
      +---------------------+
      | register save area  |
      +---------------------+  <---+ SP

Thus StgRun must also allocate a register save area which is used by subsequent
C functions.  An example stack while calling StgRun could look as follows:

      .                     .
      .                     .
      |                     |
      +---------------------+
RSA1  | register save area  |
      | used by StgRun      |
      +---------------------+ xxx
      |                     |   xx
      |                     |    xx
      |                     |     xx
      |                     |     xx
      |                     |      xxxxxx RESERVED_C_STACK_BYTES
      |                     |     xx
      |                     |     xx
      |                     |    xx
      |                     |   xx
      +---------------------+ xxx
RSA2  | register save area  |
      | for further C calls |
      +---------------------+  <---+ SP

RSA1 is allocated by the caller of StgRun and is used by StgRun in order to
save all callee-saved registers.  StgRun itself then allocates
RESERVED_C_STACK_BYTES many bytes and RSA2.  RSA2 will be used by subsequent C
functions which are called from STG land.

Thus coming back to my initial question how is an STG function supposed to know
where the reserved area starts?  One way would be to use SP + len(RSA2) but
this would mean an STG function is aware of the register in which the C stack
pointer is hold and the length of a register save area.  I didn't find anything
which suggests this while skimming over the code.

Many thanks and kind regards,
Stefan

From ben at well-typed.com  Sat Jun 22 15:01:01 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 22 Jun 2019 11:01:01 -0400
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>
Message-ID: <877e9dy89j.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes.
>
Yes, this release will target LLVM 7. I'll add a mention to the release notes.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190622/26321887/attachment.sig>

From andrey.mokhov at newcastle.ac.uk  Sun Jun 23 00:06:30 2019
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Sun, 23 Jun 2019 00:06:30 +0000
Subject: Hadrian: Suddenly a full build fails with: Rules may not be
 recursive
References: <DB7PR07MB59304F1F366F38B4773043ACA5E10@DB7PR07MB5930.eurprd07.prod.outlook.com>
Message-ID: <WM!e3cbb00ac78a50bbe9161dbacb681c70cbbb2d1168980e6aade0a58890a7041e10619df497f9e20e8971fd95f59d5a4c!@mailhub-mx5.ncl.ac.uk>

Hi all,

> I think this is because `--configure` is currently broken
> https://gitlab.haskell.org/ghc/ghc/issues/16809. You can work around by
> running bootstrap and configure manually for now.

Here is a merge request with a fix: https://gitlab.haskell.org/ghc/ghc/merge_requests/1255

Cheers,
Andrey


From george.colpitts at gmail.com  Sun Jun 23 15:00:36 2019
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 23 Jun 2019 12:00:36 -0300
Subject: new llvm IR callbr instruction useful for proc-point splitting?
In-Reply-To: <877e9dy89j.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>
 <877e9dy89j.fsf@smart-cactus.org>
Message-ID: <CAB-d4A5S=Og2-1N07LqYbg64UEX1FWMWXKn_GeCQguZ2Gin6AA@mail.gmail.com>

Hi

I hope this question isn't too dumb. llvm has a new callbr instruction to
implement asm-goto

   - http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
   -
   https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Asm-Goto-Merged

Could this be used to avoid proc-point splitting
<https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/backend-opt>?

Thanks
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190623/a11d799c/attachment.html>

From matthewtpickering at gmail.com  Mon Jun 24 09:04:34 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 24 Jun 2019 10:04:34 +0100
Subject: Modify quickstart page to use hadrian rather than make?
Message-ID: <CALuQ0m-s5psaYmWuvRiDyC+3_P8hTsBw16qVZhPVrzNfNHOkQw@mail.gmail.com>

Hi all,

I propose that we modify the quickstart page so that the instructions
use hadrian rather than make.

At this point I don't see why a newcomer should have to use the make
build system.

https://gitlab.haskell.org/ghc/ghc/wikis/building/quick-start

Cheers,

Matt

From shayne.fletcher at daml.com  Mon Jun 24 09:26:58 2019
From: shayne.fletcher at daml.com (Shayne Fletcher)
Date: Mon, 24 Jun 2019 05:26:58 -0400
Subject: Modify quickstart page to use hadrian rather than make?
In-Reply-To: <CALuQ0m-s5psaYmWuvRiDyC+3_P8hTsBw16qVZhPVrzNfNHOkQw@mail.gmail.com>
References: <CALuQ0m-s5psaYmWuvRiDyC+3_P8hTsBw16qVZhPVrzNfNHOkQw@mail.gmail.com>
Message-ID: <CAKe9RRHMt0cxf19Vdak3z1QJSQESXyhkErKTOtqpbBf9HbHHLg@mail.gmail.com>

On Mon, Jun 24, 2019 at 5:05 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi all,
>
> I propose that we modify the quickstart page so that the instructions
> use hadrian rather than make.
>
> At this point I don't see why a newcomer should have to use the make
> build system.
>
> https://gitlab.haskell.org/ghc/ghc/wikis/building/quick-start
>
>
I second this. I would go further and advocate that such instructions
should include passing the `--configure`flag.


> Cheers,
>
> Matt
>

-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

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

From kavon at farvard.in  Mon Jun 24 16:14:35 2019
From: kavon at farvard.in (Kavon Farvardin)
Date: Mon, 24 Jun 2019 11:14:35 -0500
Subject: new llvm IR callbr instruction useful for proc-point splitting?
In-Reply-To: <CAB-d4A5S=Og2-1N07LqYbg64UEX1FWMWXKn_GeCQguZ2Gin6AA@mail.gmail.com>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>
 <877e9dy89j.fsf@smart-cactus.org>
 <CAB-d4A5S=Og2-1N07LqYbg64UEX1FWMWXKn_GeCQguZ2Gin6AA@mail.gmail.com>
Message-ID: <a876f857876430b7b089ef6a0241aaeee776c45a.camel@farvard.in>

Yes, callbr is part of the discussion on removing proc-point splitting! 
Soon there will be an announcement about a new working group dedicated to LLVM
issues such as this one on this mailing list. Anyone interested is welcome to
join our meetings.
We're currently gathering our notes together first, but you can have a look here
for a preview: 
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Optimization
On Sun, 2019-06-23 at 12:00 -0300, George Colpitts wrote:
> Hi
> 
> I hope this question isn't too dumb. llvm has a new callbr instruction to
> implement asm-goto 
> http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
> https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Asm-Goto-Merged
> Could this be used to avoid proc-point splitting?
> 
> Thanks
> George
> 
> 
> 
> _______________________________________________ghc-devs mailing listghc-
> devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190624/69f6f0d2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190624/69f6f0d2/attachment.sig>

From chessai1996 at gmail.com  Mon Jun 24 17:52:43 2019
From: chessai1996 at gmail.com (chessai .)
Date: Mon, 24 Jun 2019 13:52:43 -0400
Subject: gitlab.haskell.org down?
Message-ID: <CAD34_kJEA_Sii2UpBEdR9aZL5E=fsD9qZED2m+4pu=Y5dUaBqw@mail.gmail.com>

hi devs,

I tried doing a fresh clone of ghc with

git clone --recursive https://gitlab.haskell.org/ghc/ghc

and got

Cloning into 'ghc'...
warning: redirecting to https://gitlab.haskell.org/ghc/ghc.git/
remote: Enumerating objects: 521560, done.
remote: Counting objects: 100% (521560/521560), done.
remote: Compressing objects: 100% (107771/107771), done.
fatal: the remote end hung up unexpectedly0.39 MiB | 9.50 MiB/s
fatal: early EOF
fatal: index-pack failed

Trying again, with the same command, within a minute afterward, I got:

Cloning into 'ghc'...
fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': The
requested URL returned error: 502

I also get a 502 when going to the haskell gitlab page.

From alan.zimm at gmail.com  Mon Jun 24 18:07:54 2019
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 24 Jun 2019 20:07:54 +0200
Subject: gitlab.haskell.org down?
In-Reply-To: <CAD34_kJEA_Sii2UpBEdR9aZL5E=fsD9qZED2m+4pu=Y5dUaBqw@mail.gmail.com>
References: <CAD34_kJEA_Sii2UpBEdR9aZL5E=fsD9qZED2m+4pu=Y5dUaBqw@mail.gmail.com>
Message-ID: <CANma=H-KeVHg8j0Ji-FP-yyx11Om6EXrjehMOG8BpF2L196ZqA@mail.gmail.com>

FWIW I've been having ssl connections going flaky all day, and just had a
(transient) 502 on a git update from
https://git.savannah.gnu.org/git/guix.git

502 is a gateway timeout, maybe it is the CDNs gone flaky

Alan

On Mon, 24 Jun 2019 at 19:53, chessai . <chessai1996 at gmail.com> wrote:

> hi devs,
>
> I tried doing a fresh clone of ghc with
>
> git clone --recursive https://gitlab.haskell.org/ghc/ghc
>
> and got
>
> Cloning into 'ghc'...
> warning: redirecting to https://gitlab.haskell.org/ghc/ghc.git/
> remote: Enumerating objects: 521560, done.
> remote: Counting objects: 100% (521560/521560), done.
> remote: Compressing objects: 100% (107771/107771), done.
> fatal: the remote end hung up unexpectedly0.39 MiB | 9.50 MiB/s
> fatal: early EOF
> fatal: index-pack failed
>
> Trying again, with the same command, within a minute afterward, I got:
>
> Cloning into 'ghc'...
> fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': The
> requested URL returned error: 502
>
> I also get a 502 when going to the haskell gitlab page.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190624/f7ef4d68/attachment.html>

From mail at nh2.me  Mon Jun 24 20:43:52 2019
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Mon, 24 Jun 2019 22:43:52 +0200
Subject: gitlab.haskell.org down?
In-Reply-To: <CANma=H-KeVHg8j0Ji-FP-yyx11Om6EXrjehMOG8BpF2L196ZqA@mail.gmail.com>
References: <CAD34_kJEA_Sii2UpBEdR9aZL5E=fsD9qZED2m+4pu=Y5dUaBqw@mail.gmail.com>
 <CANma=H-KeVHg8j0Ji-FP-yyx11Om6EXrjehMOG8BpF2L196ZqA@mail.gmail.com>
Message-ID: <19b61137-d6e3-ee0d-ff1d-6620d7cc134a@nh2.me>

Not sure if the reason, but there was a BGP problem on the Internet today:

https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/

On 24/06/2019 8:07 PM, Alan & Kim Zimmerman wrote:
> 502 is a gateway timeout, maybe it is the CDNs gone flaky

From ben at smart-cactus.org  Mon Jun 24 20:57:03 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 24 Jun 2019 16:57:03 -0400
Subject: Why is NoExt inhabited?
Message-ID: <87sgrywvl3.fsf@smart-cactus.org>

Hi Shayan,

During code review a contributor asked about a TTG extension point.
While answering his question I realized I didn't have a good explanation
for why NoExt is inhabited; as far as I can tell it should rather be
unhabited.

If there is a reason for this then can you:

 1. describe why this is so in #16863 [1]
 2. open an MR documenting the reason in Note [Trees that Grow].

If not, perhaps we should consider changing it; the current state of
things is a bit awkward.

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/issues/16863
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190624/40f2ede9/attachment.sig>

From ben at smart-cactus.org  Mon Jun 24 21:23:06 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 24 Jun 2019 17:23:06 -0400
Subject: new llvm IR callbr instruction useful for proc-point splitting?
In-Reply-To: <a876f857876430b7b089ef6a0241aaeee776c45a.camel@farvard.in>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAB-d4A6QyumkF3LLc8rk=NQ4jTVDOqXmo5AWOOQ2=qZr6E8JPQ@mail.gmail.com>
 <877e9dy89j.fsf@smart-cactus.org>
 <CAB-d4A5S=Og2-1N07LqYbg64UEX1FWMWXKn_GeCQguZ2Gin6AA@mail.gmail.com>
 <a876f857876430b7b089ef6a0241aaeee776c45a.camel@farvard.in>
Message-ID: <87pnn2wudm.fsf@smart-cactus.org>

Kavon Farvardin <kavon at farvard.in> writes:

> Yes, callbr is part of the discussion on removing proc-point splitting! 
> Soon there will be an announcement about a new working group dedicated to LLVM
> issues such as this one on this mailing list. Anyone interested is welcome to
> join our meetings.
> We're currently gathering our notes together first, but you can have a look here
> for a preview: 
> https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Optimization

I, for one, would love to see us try using the native stack register for
reasons entirely separate from performance. Namely, it would make using
existing debugging and performance analysis tools (e.g. perf) much
easier.

I believe that Andreas Klebinger has also suggested moving return point
info tables away from code. It would be interesting to get an estimate
of the size of this effect on performance.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190624/3705b0c7/attachment.sig>

From simonpj at microsoft.com  Mon Jun 24 21:59:07 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Jun 2019 21:59:07 +0000
Subject: StgRun and reserved C stack space
In-Reply-To: <20190622092306.GA17249@localhost.localdomain>
References: <20190622092306.GA17249@localhost.localdomain>
Message-ID: <VI1PR83MB03190D48FC4CAAF69BB2547DADE00@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Perhaps Simon Marlow, or others, may be able to help?

It would be good to capture the answers somewhere, perhaps in the GHC Commentary?
https://gitlab.haskell.org/ghc/ghc/wikis/commentary

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Stefan Schulze
| Frielinghaus
| Sent: 22 June 2019 10:23
| To: ghc-devs at haskell.org
| Subject: StgRun and reserved C stack space
| 
| Hi all,
| 
| I'm trying to understand how StgRun/StgReturn are supposed to be
| implemented.
| My current understanding is that StgRun is called from C land in order to
| save all callee-saved registers, allocate some stack space, and then
| finally jump to an STG function.  StgReturn is the counterpart of StgRun
| and is called from STG land in order to restore all callee-saved
| registers, free the previously allocated stack space, and finally return
| to C land.
| 
| Assuming that my intuition is correct I still have some concerns regarding
| the stack space which is allocated by StgRun.  StgRun allocates
| RESERVED_C_STACK_BYTES many bytes on the C stack.  However, I cannot see
| how an STG function is supposed to access this reserved area since no
| pointer is derived or whatsoever.  Does an STG function make use of the C
| stack pointer and assume that the reserved area is at the very bottom of
| the stack?
| 
| Lets make an example.  Assume the C ABI demands that every function
| allocates a Register Save Area (RSA for short) at the bottom of a stack
| frame which may be used by a subsequent C function.  That means a caller
| allocates some stack space for its callee.  This area must be below the
| local variable and parameter area which means it is at the very bottom of
| a stack frame.  A C stack frame then looks as follows:
| 
|       .                     .
|       .                     .
|       | previous frame      |
|       +---------------------+
|       | local variables     |
|       +---------------------+
|       | parameter area      |
|       +---------------------+
|       | register save area  |
|       +---------------------+  <---+ SP
| 
| Thus StgRun must also allocate a register save area which is used by
| subsequent C functions.  An example stack while calling StgRun could look
| as follows:
| 
|       .                     .
|       .                     .
|       |                     |
|       +---------------------+
| RSA1  | register save area  |
|       | used by StgRun      |
|       +---------------------+ xxx
|       |                     |   xx
|       |                     |    xx
|       |                     |     xx
|       |                     |     xx
|       |                     |      xxxxxx RESERVED_C_STACK_BYTES
|       |                     |     xx
|       |                     |     xx
|       |                     |    xx
|       |                     |   xx
|       +---------------------+ xxx
| RSA2  | register save area  |
|       | for further C calls |
|       +---------------------+  <---+ SP
| 
| RSA1 is allocated by the caller of StgRun and is used by StgRun in order
| to save all callee-saved registers.  StgRun itself then allocates
| RESERVED_C_STACK_BYTES many bytes and RSA2.  RSA2 will be used by
| subsequent C functions which are called from STG land.
| 
| Thus coming back to my initial question how is an STG function supposed to
| know where the reserved area starts?  One way would be to use SP +
| len(RSA2) but this would mean an STG function is aware of the register in
| which the C stack pointer is hold and the length of a register save area.
| I didn't find anything which suggests this while skimming over the code.
| 
| Many thanks and kind regards,
| Stefan
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9b1c5c94f5a14f3d11c308d6
| f6f34a3d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636967922119470764&a
| mp;sdata=cYAlP9xb%2F%2FeoYy%2Bq4M66IomjxX90HtwgPpSf2mvYX5U%3D&amp;reserved
| =0

From rae at richarde.dev  Tue Jun 25 03:21:57 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 24 Jun 2019 23:21:57 -0400
Subject: Why is NoExt inhabited?
In-Reply-To: <87sgrywvl3.fsf@smart-cactus.org>
References: <87sgrywvl3.fsf@smart-cactus.org>
Message-ID: <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>

I forget if I'm the contributor Ben mentions below, but regardless: NoExt is used in two separate ways within GHC. It's used both as the extension of a sum (new constructor) and the extension of a product (new field in a constructor). But the identity for sum is different than the identity for products. To me, it makes good sense for the NoExt used as a product extension (new field) to have the 1 trivial inhabitant (thus forming the identity for products), but the NoExt used as a sum extension (new constructor) to have 0 inhabitants (thus forming the identity for sums). Clearly, one of these will need a new name.

Thanks,
Richard

> On Jun 24, 2019, at 4:57 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Hi Shayan,
> 
> During code review a contributor asked about a TTG extension point.
> While answering his question I realized I didn't have a good explanation
> for why NoExt is inhabited; as far as I can tell it should rather be
> unhabited.
> 
> If there is a reason for this then can you:
> 
> 1. describe why this is so in #16863 [1]
> 2. open an MR documenting the reason in Note [Trees that Grow].
> 
> If not, perhaps we should consider changing it; the current state of
> things is a bit awkward.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://gitlab.haskell.org/ghc/ghc/issues/16863
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From arnaud.spiwack at tweag.io  Tue Jun 25 06:59:09 2019
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 25 Jun 2019 08:59:09 +0200
Subject: Why is NoExt inhabited?
In-Reply-To: <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>
References: <87sgrywvl3.fsf@smart-cactus.org>
 <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>
Message-ID: <CAH6fHQmqtxVqdUbryaHbeJu3ifgj3AKnCS8pqPojpmCQOczxvQ@mail.gmail.com>

NoFExt (“Field”) and NoCExt (“Constructor”), maybe?

On Tue, Jun 25, 2019 at 5:22 AM Richard Eisenberg <rae at richarde.dev> wrote:

> I forget if I'm the contributor Ben mentions below, but regardless: NoExt
> is used in two separate ways within GHC. It's used both as the extension of
> a sum (new constructor) and the extension of a product (new field in a
> constructor). But the identity for sum is different than the identity for
> products. To me, it makes good sense for the NoExt used as a product
> extension (new field) to have the 1 trivial inhabitant (thus forming the
> identity for products), but the NoExt used as a sum extension (new
> constructor) to have 0 inhabitants (thus forming the identity for sums).
> Clearly, one of these will need a new name.
>
> Thanks,
> Richard
>
> > On Jun 24, 2019, at 4:57 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> >
> > Hi Shayan,
> >
> > During code review a contributor asked about a TTG extension point.
> > While answering his question I realized I didn't have a good explanation
> > for why NoExt is inhabited; as far as I can tell it should rather be
> > unhabited.
> >
> > If there is a reason for this then can you:
> >
> > 1. describe why this is so in #16863 [1]
> > 2. open an MR documenting the reason in Note [Trees that Grow].
> >
> > If not, perhaps we should consider changing it; the current state of
> > things is a bit awkward.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://gitlab.haskell.org/ghc/ghc/issues/16863
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190625/0dadf019/attachment.html>

From simonpj at microsoft.com  Tue Jun 25 08:52:15 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 25 Jun 2019 08:52:15 +0000
Subject: Cloning
Message-ID: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>

What is the right procedure for cloning from someone else's repo.
For example, I wanted to see what was going wrong for Tobias in #16615, so after some detective work I tried
git clone --recursive git at gitlab.haskell.org:tdammers/ghc.git tdammers
but I got lots of errors:

Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

> GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git at gitlab.haskell.org:tdammers/libffi-tarballs.git' into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed

Failed to clone 'libffi-tarballs'. Retry scheduled

Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

> GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git at gitlab.haskell.org:tdammers/packages/Cabal.git' into submodule path
etc etc.
So:

  *   What is a reliable way to get a MR onto my machine to test?
  *   If I make a fix, what is the workflow to push that fix back to the author -- presumably I can't push to their repo?
Thanks
Simon


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

From a.pelenitsyn at gmail.com  Tue Jun 25 09:04:44 2019
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Tue, 25 Jun 2019 12:04:44 +0300
Subject: Cloning
In-Reply-To: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <CAPKAvQUi-xq=iXz-CU78TkVe8LSKXHk+Ki5QNQQdH9JnhpXecQ@mail.gmail.com>

Dear Simon,

In order for submodules to work, you still have to jump through the main
repo. That is,

git clone --recursive https://gitlab.haskell.org/ghc/ghc tdammers
cd tdammers
git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git
git checkout tdammers some-branch

Dear ghc-devs,
More generally, I'm actually wondering, why GHC's .gitsubmodules use
relative paths.  Why not make them absolute?

--
Best wishes,
Artem

On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> What is the right procedure for cloning from someone else’s repo.
>
> For example, I wanted to see what was going wrong for Tobias in #16615, so
> after some detective work I tried
>
> git clone --recursive git at gitlab.haskell.org:tdammers/ghc.git tdammers
>
> but I got lots of errors:
>
> Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> > GitLab: The project you were looking for could not be found.
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> fatal: clone of 'git at gitlab.haskell.org:tdammers/libffi-tarballs.git'
> into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed
>
> Failed to clone 'libffi-tarballs'. Retry scheduled
>
> Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...
>
> setsockopt IPV6_TCLASS 8: Operation not permitted:
>
> > GitLab: The project you were looking for could not be found.
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> fatal: clone of 'git at gitlab.haskell.org:tdammers/packages/Cabal.git' into
> submodule path
>
> etc etc.
>
> So:
>
>    - What is a reliable way to get a MR onto my machine to test?
>    - If I make a fix, what is the workflow to push that fix back to the
>    author -- presumably I can’t push to their repo?
>
> Thanks
>
> Simon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190625/aa9ef2c2/attachment.html>

From a.pelenitsyn at gmail.com  Tue Jun 25 09:10:30 2019
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Tue, 25 Jun 2019 12:10:30 +0300
Subject: Cloning
In-Reply-To: <CAPKAvQUi-xq=iXz-CU78TkVe8LSKXHk+Ki5QNQQdH9JnhpXecQ@mail.gmail.com>
References: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CAPKAvQUi-xq=iXz-CU78TkVe8LSKXHk+Ki5QNQQdH9JnhpXecQ@mail.gmail.com>
Message-ID: <CAPKAvQWDxnE0G158jN-3Rm5kYuWy9GmwOLg6ichJUbeTaEw4=A@mail.gmail.com>

Actually, I forgot to pull:

git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git
> git pull tdammers
git checkout tdammers some-branch

And to post changes to, say, GHC's main repo:

git push origin some-branch

-- Artem

On Tue, 25 Jun 2019 at 12:04, Artem Pelenitsyn <a.pelenitsyn at gmail.com>
wrote:

> Dear Simon,
>
> In order for submodules to work, you still have to jump through the main
> repo. That is,
>
> git clone --recursive https://gitlab.haskell.org/ghc/ghc tdammers
> cd tdammers
> git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git
> git checkout tdammers some-branch
>
> Dear ghc-devs,
> More generally, I'm actually wondering, why GHC's .gitsubmodules use
> relative paths.  Why not make them absolute?
>
> --
> Best wishes,
> Artem
>
> On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>> What is the right procedure for cloning from someone else’s repo.
>>
>> For example, I wanted to see what was going wrong for Tobias in #16615,
>> so after some detective work I tried
>>
>> git clone --recursive git at gitlab.haskell.org:tdammers/ghc.git tdammers
>>
>> but I got lots of errors:
>>
>> Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...
>>
>> setsockopt IPV6_TCLASS 8: Operation not permitted:
>>
>> > GitLab: The project you were looking for could not be found.
>>
>> fatal: Could not read from remote repository.
>>
>>
>>
>> Please make sure you have the correct access rights
>>
>> and the repository exists.
>>
>> fatal: clone of 'git at gitlab.haskell.org:tdammers/libffi-tarballs.git'
>> into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed
>>
>> Failed to clone 'libffi-tarballs'. Retry scheduled
>>
>> Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...
>>
>> setsockopt IPV6_TCLASS 8: Operation not permitted:
>>
>> > GitLab: The project you were looking for could not be found.
>>
>> fatal: Could not read from remote repository.
>>
>>
>>
>> Please make sure you have the correct access rights
>>
>> and the repository exists.
>>
>> fatal: clone of 'git at gitlab.haskell.org:tdammers/packages/Cabal.git'
>> into submodule path
>>
>> etc etc.
>>
>> So:
>>
>>    - What is a reliable way to get a MR onto my machine to test?
>>    - If I make a fix, what is the workflow to push that fix back to the
>>    author -- presumably I can’t push to their repo?
>>
>> Thanks
>>
>> Simon
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190625/43a29266/attachment.html>

From simonpj at microsoft.com  Tue Jun 25 09:29:22 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 25 Jun 2019 09:29:22 +0000
Subject: Cloning
In-Reply-To: <CAPKAvQWDxnE0G158jN-3Rm5kYuWy9GmwOLg6ichJUbeTaEw4=A@mail.gmail.com>
References: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CAPKAvQUi-xq=iXz-CU78TkVe8LSKXHk+Ki5QNQQdH9JnhpXecQ@mail.gmail.com>
 <CAPKAvQWDxnE0G158jN-3Rm5kYuWy9GmwOLg6ichJUbeTaEw4=A@mail.gmail.com>
Message-ID: <VI1PR83MB0319BDACAF7B8257D9BF699EADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Thanks.  I think I understand.  The model is


  *   Always start from a clone of the main repo; do not attempt to clone anyone else’s
  *   Add the extra repo as a remote
  *   Check out a branch from it.

I had not previously understood that -- thanks

S

From: Artem Pelenitsyn <a.pelenitsyn at gmail.com>
Sent: 25 June 2019 10:11
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: Cloning

Actually, I forgot to pull:

git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git<mailto:git at gitlab.haskell.org:tdammers/ghc.git>
> git pull tdammers
git checkout tdammers some-branch

And to post changes to, say, GHC's main repo:

git push origin some-branch

-- Artem

On Tue, 25 Jun 2019 at 12:04, Artem Pelenitsyn <a.pelenitsyn at gmail.com<mailto:a.pelenitsyn at gmail.com>> wrote:
Dear Simon,

In order for submodules to work, you still have to jump through the main repo. That is,

git clone --recursive https://gitlab.haskell.org/ghc/ghc<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C52fa9c0222914fd9d33608d6f94d006e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636970506449242123&sdata=b7df1dvmZW%2FRxJow7tiVYtFxopJkrk6AKad0aD%2Bsmwo%3D&reserved=0> tdammers
cd tdammers
git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git<mailto:git at gitlab.haskell.org:tdammers/ghc.git>
git checkout tdammers some-branch

Dear ghc-devs,
More generally, I'm actually wondering, why GHC's .gitsubmodules use relative paths.  Why not make them absolute?

--
Best wishes,
Artem

On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
What is the right procedure for cloning from someone else’s repo.
For example, I wanted to see what was going wrong for Tobias in #16615, so after some detective work I tried
git clone --recursive git at gitlab.haskell.org:tdammers/ghc.git<mailto:git at gitlab.haskell.org:tdammers/ghc.git> tdammers
but I got lots of errors:

Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

> GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git at gitlab.haskell.org:tdammers/libffi-tarballs.git' into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed

Failed to clone 'libffi-tarballs'. Retry scheduled

Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

> GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git at gitlab.haskell.org:tdammers/packages/Cabal.git' into submodule path
etc etc.
So:

  *   What is a reliable way to get a MR onto my machine to test?
  *   If I make a fix, what is the workflow to push that fix back to the author -- presumably I can’t push to their repo?
Thanks
Simon


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<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%7C52fa9c0222914fd9d33608d6f94d006e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636970506449252119&sdata=Xm6rW0Ehl7R9lSSghWDc%2BzQOPKmeI4n92eMugmgcZbg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190625/100a377c/attachment-0001.html>

From shayne.fletcher at daml.com  Tue Jun 25 10:31:25 2019
From: shayne.fletcher at daml.com (Shayne Fletcher)
Date: Tue, 25 Jun 2019 06:31:25 -0400
Subject: Cloning
In-Reply-To: <VI1PR83MB0319BDACAF7B8257D9BF699EADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
References: <VI1PR83MB03190243C1D1B278F75E8754ADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
 <CAPKAvQUi-xq=iXz-CU78TkVe8LSKXHk+Ki5QNQQdH9JnhpXecQ@mail.gmail.com>
 <CAPKAvQWDxnE0G158jN-3Rm5kYuWy9GmwOLg6ichJUbeTaEw4=A@mail.gmail.com>
 <VI1PR83MB0319BDACAF7B8257D9BF699EADE30@VI1PR83MB0319.EURPRD83.prod.outlook.com>
Message-ID: <CAKe9RRH8OidXMXw6JZcGVYXgzeOriqZ6tKiVZRC+KsWzknvGYg@mail.gmail.com>

On Tue, Jun 25, 2019 at 5:29 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> Thanks.  I think I understand.  The model is
>
>
>
>    - Always start from a clone of the main repo; do not attempt to clone
>    anyone else’s
>    - Add the extra repo as a remote
>    - Check out a branch from it.
>
>
>
> I had not previously understood that -- thanks
>
>
>

That's exactly it. My work finds me doing this sort of thing quite a lot. I
don't know if my (the following) approach is overkill however, it works
reliably for me.
```
# Clone the main repo
git clone https://gitlab.haskell.org/ghc/ghc.git
# Add remote
git remote add tdammers git at gitlab.haskell.org:tdammers/ghc.git
# Get remote's branches
git fetch tdammers
# Roll the main repo back to where tdammers /some-branch started
git checkout `git merge-base tdammers/some-branch master`
# Retrieve sub-modules as they were at that point
git submodule update --init --recursive
# Now switch to the remote branch
git checkout -t tdammers/some-branch
```

> More generally, I'm actually wondering, why GHC's .gitsubmodules use
relative paths.  Why not make them absolute?

I continue to wonder about that and if switching to absolute paths might
remove this wrinkle. Can anyone chime in?

-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

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

From rmduarte at inf.ufpel.edu.br  Wed Jun 26 13:42:13 2019
From: rmduarte at inf.ufpel.edu.br (Rodrigo Duarte)
Date: Wed, 26 Jun 2019 10:42:13 -0300
Subject: Preemption a haskell thread inside a Transaction
Message-ID: <CAPRtcxm1B_1jvEj73RyoHnE6LYDrRATzawfJD+KkQei_dYPeLg@mail.gmail.com>

Hi
I am trying to modify the GHC rts so that every time a transaction fails to
commit, instead of automatically restart it,
I want to preempted and add it to the end of the task queue of its HEC.

The problem is, when I try to call  yield at the point of the
 ATOMICALLY_FRAME code where the transaction is restarted,
I get this error message:

>>Main: Control.Concurrent.STM.atomically was nested
>>Main: thread blocked indefinitely in an MVar operation

The point in the code of PrimOps.cmm I try to put my code is as below.

PrimOps.cmm
1074   /* Transaction was not valid: try again */
1075        ("ptr" trec) = ccall stmStartTransaction(MyCapability() "ptr",
1076                                                 NO_TREC "ptr");
1077        StgTSO_trec(CurrentTSO) = trec;
1078
1079 /* call yield function here */
            Capability_context_switch(MyCapability()) = 1 :: CInt;
            jump stg_yield_noregs();
            /*                          */
1080        jump stg_ap_v_fast
1081            // push the StgAtomicallyFrame again: the code generator is
1082            // clever enough to only assign the fields that have
changed.
1083            (ATOMICALLY_FRAME_FIELDS(,,info_ptr,p1,p2,
1084                                     code,frame_result))
1085            (code);


My doubts are:
    Is it possible to make a preemption at that point in the
ATOMICALLY_FRAME code?. If it is possible, how do I proceed?

Thanks for the attention.
Best regards.

-- 
*Rodrigo M. Duarte*
Bacharelado em Engenharia de Computação
LUPS - Laboratory of Ubiquitous and Parallel Systems
Computação de Alto Desempenho Sustentável
Universidade Federal de Pelotas - UFPel

[image: image_png_part?hl=pt&part=2&thumb=1]

*Antes de imprimir este e-mail pense em sua responsabilidade e compromisso
com o Meio Ambiente. **Só imprima se for realmente necessário. *


*Before printing this e-mail consider its responsibility and commitment to
the environment. Only print if it is really necessary. *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190626/5a03f681/attachment.html>

From ben at well-typed.com  Thu Jun 27 17:26:15 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 27 Jun 2019 13:26:15 -0400
Subject: The future of the SPARC NCG backend
Message-ID: <87d0izvt1n.fsf@smart-cactus.org>

Hello everyone,

If you use (or think you might use in the future) GHC's SPARC NCG
backend please do leave a note on #16882 [1]. My impression is that it
has no users and no plausible means of testing. Consequently I am
suggesting that we remove it in GHC 8.12.

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/issues/16882
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190627/5df9e1a8/attachment.sig>

From juhpetersen at gmail.com  Fri Jun 28 03:58:23 2019
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 28 Jun 2019 11:58:23 +0800
Subject: [ANNOUNCE] GHC 8.8.1-alpha2 is now available
In-Reply-To: <87tvcpy2mn.fsf@smart-cactus.org>
References: <874l4qzlny.fsf@smart-cactus.org>
 <CAEDGBqKUdh9jTa8ZKoP54SvXDmhqHE4xzTXGjRSN_5us-rUv-A@mail.gmail.com>
 <87tvcpy2mn.fsf@smart-cactus.org>
Message-ID: <CAEDGBqJ1tHNi8ifEVXZPuG_T4p_WLxYS-Xygt+609BysgJP0OQ@mail.gmail.com>

Thanks, I forgot to follow up that I updated the Fedora ghc:8.8 module
stream to alpha2 for F30+.

Though it fails sometimes on s390x (gcc failure).

From omeragacan at gmail.com  Fri Jun 28 09:09:45 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 28 Jun 2019 12:09:45 +0300
Subject: Workflow question (changing codegen)
Message-ID: <CAMQQO3kyb_XB_RKY65YTatb9a52t_LJ2xymw9rcvWL0MK2EWjA@mail.gmail.com>

Hi all,

I'm currently going through this torturous process and I'm hoping that someone
here will be able to help.

I'm making changes in the codegen. My changes are currently buggy, and I need a
working stage 1 compiler to be able to debug. Basically I need to build
libraries using the branch my changes are based on, then build stage 1 with my
branch, so that I'll be able to build and run programs using stage 1 that uses
my codegen changes. The changes are compatible with the old codegen (i.e. no
changes in calling conventions or anything like that) so this should work.

Normally I do this

    $ git checkout master
    $ git distclean && ./boot && ./configure && make
    $ git checkout my_branch
    $ cd compiler; make 1

This gives me stage 1 compiler that uses my buggy codegen changes, plus
libraries built with the old and correct codegen.

However the problem is I'm also adding a new file in my_branch, and the build
system just doesn't register that fact, even after adding the line I added to
compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix this
that I could find was to run ./configure again, then run make for a few seconds
at the top level, then do `make 1` in compiler/. Unfortunately even that doesn't
work when the master branch and my_branch have different dates, because `make`
in master branch produces a different version than the `make` in my_branch, so
the interface files become incompatible.

Anyone have any ideas on how to proceed here?

Thanks,

Ömer

From trupill at gmail.com  Fri Jun 28 12:11:58 2019
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jun 2019 14:11:58 +0200
Subject: Guarded Impredicativity
Message-ID: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>

Dear all,

We are trying to bring back `ImpredicativeTypes` into GHC by using the
ideas in the "Guarded Impredicative Polymorphism" paper [
https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
].

For now I have produced a first attempt, which lives in
https://gitlab.haskell.org/trupill/ghc. It would be great if those
interested in impredicative polymorphism could give it a try and see
whether it works as expected or not.

The main idea behing "guarded impredicativity" is that you can infer an
impredicative instantiation for a type variable in a function call if you
have at least one given argument where that type variable appears under a
type constructor different from (->).
For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a.
a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`,
the variable `a` appears under the `[]` constructor and that second
argument is given, we are allowed to instantiate `a := forall a. a -> a`.
On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid
concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced
to instantiate `m` with a not-polymorphic type because at no point the
variable appears under a type constructor.

Just for reference, the best to get a working clone is to follow these
steps:
> git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc
> cd impredicative-ghc
> git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> git fetch trupill
> git checkout trupill master

Thanks very much in advance,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/64b754be/attachment.html>

From simonpj at microsoft.com  Fri Jun 28 12:15:24 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 28 Jun 2019 12:15:24 +0000
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
Message-ID: <VI1PR83MB031958487B0A8F0DFEC1866AADFC0@VI1PR83MB0319.EURPRD83.prod.outlook.com>

Just to amplify: we are very interested to


  *   Get some idea of whether anyone  cares about impredicativity.  If we added it to GHC, would you use it?  Have you ever bumped up Haskell’s inability to instantiate a polymorphic function at a polytype.



  *   Get some idea of whether the particular form of impredicativity described in the paper would be expressive enough for your application.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 28 June 2019 13:12
To: ghc-devs at haskell.org
Subject: Guarded Impredicativity

Dear all,

We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fpublication%2Fguarded-impredicative-polymorphism%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2d42d6134644b3d128a08d6fbc1e36d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636973207496244478&sdata=o8H3dd5tLDRCGpwzsq6BMwNwYepPQgmoKsrXtLbJQdk%3D&reserved=0>].

For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Ftrupill%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2d42d6134644b3d128a08d6fbc1e36d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636973207496244478&sdata=TGegIFjwdjJ7XPdmlVNY3wve385FalfVLaW1YLCiXlM%3D&reserved=0>. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not.

The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->).
For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor.

Just for reference, the best to get a working clone is to follow these steps:
> git clone --recursive https://gitlab.haskell.org/ghc/ghc<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2d42d6134644b3d128a08d6fbc1e36d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636973207496254471&sdata=hXtR8j0th3U65DW7MvaofVW8tq7pubXUJqlyflGSBPw%3D&reserved=0> impredicative-ghc
> cd impredicative-ghc
> git remote add trupill git at gitlab.haskell.org:trupill/ghc.git<mailto:git at gitlab.haskell.org:trupill/ghc.git>
> git fetch trupill
> git checkout trupill master

Thanks very much in advance,
Alejandro

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

From matthewtpickering at gmail.com  Fri Jun 28 12:17:01 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 28 Jun 2019 13:17:01 +0100
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
Message-ID: <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>

Have you modified how typed quotations are type checked? For example,
with your patch I would hope that

[| id |] :: Code (forall a . a -> a)

would be accepted?

I'll try it out. This patch will have big ramifications for the typed
template haskell community.

Matt

On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
<trupill at gmail.com> wrote:
>
> Dear all,
>
> We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/].
>
> For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not.
>
> The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->).
> For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor.
>
> Just for reference, the best to get a working clone is to follow these steps:
> > git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc
> > cd impredicative-ghc
> > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> > git fetch trupill
> > git checkout trupill master
>
> Thanks very much in advance,
> Alejandro
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From trupill at gmail.com  Fri Jun 28 12:20:21 2019
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jun 2019 14:20:21 +0200
Subject: Guarded Impredicativity
In-Reply-To: <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
Message-ID: <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>

No, up to now the only changes are in the type checking of applications and
variables.
However, I guess that it would be possible to give [| id |] the type Code
(forall a. a -> a) with a explicit type signature (the system always allows
impredicative instantiation is explicitly marked), but without the
annotation it would the usual type forall a. Code (a -> a).

El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<
matthewtpickering at gmail.com>) escribió:

> Have you modified how typed quotations are type checked? For example,
> with your patch I would hope that
>
> [| id |] :: Code (forall a . a -> a)
>
> would be accepted?
>
> I'll try it out. This patch will have big ramifications for the typed
> template haskell community.
>
> Matt
>
> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
> <trupill at gmail.com> wrote:
> >
> > Dear all,
> >
> > We are trying to bring back `ImpredicativeTypes` into GHC by using the
> ideas in the "Guarded Impredicative Polymorphism" paper [
> https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
> ].
> >
> > For now I have produced a first attempt, which lives in
> https://gitlab.haskell.org/trupill/ghc. It would be great if those
> interested in impredicative polymorphism could give it a try and see
> whether it works as expected or not.
> >
> > The main idea behing "guarded impredicativity" is that you can infer an
> impredicative instantiation for a type variable in a function call if you
> have at least one given argument where that type variable appears under a
> type constructor different from (->).
> > For example, consider the call `(\x -> x) : ids`, where `ids :: [forall
> a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] ->
> [a]`, the variable `a` appears under the `[]` constructor and that second
> argument is given, we are allowed to instantiate `a := forall a. a -> a`.
> On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid
> concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced
> to instantiate `m` with a not-polymorphic type because at no point the
> variable appears under a type constructor.
> >
> > Just for reference, the best to get a working clone is to follow these
> steps:
> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc
> impredicative-ghc
> > > cd impredicative-ghc
> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> > > git fetch trupill
> > > git checkout trupill master
> >
> > Thanks very much in advance,
> > Alejandro
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/d775ba78/attachment.html>

From eacameron at gmail.com  Fri Jun 28 12:26:02 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Fri, 28 Jun 2019 08:26:02 -0400
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
 <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
Message-ID: <CANPxu=w1B8mdej46Qg+z0JvTsF_44mbUOEifxZaUb_VEikg3gQ@mail.gmail.com>

Sorry meant to reply all:

I ran into the error recently here:
https://github.com/monadfix/named/issues/24

trying to use a fun named arguments library. I can't immediately tell if
these changes to GHC are sufficient to help. This library is using a
newtype with phantom arguments.

On Fri, Jun 28, 2019, 8:20 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> No, up to now the only changes are in the type checking of applications
> and variables.
> However, I guess that it would be possible to give [| id |] the type Code
> (forall a. a -> a) with a explicit type signature (the system always allows
> impredicative instantiation is explicitly marked), but without the
> annotation it would the usual type forall a. Code (a -> a).
>
> El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<
> matthewtpickering at gmail.com>) escribió:
>
>> Have you modified how typed quotations are type checked? For example,
>> with your patch I would hope that
>>
>> [| id |] :: Code (forall a . a -> a)
>>
>> would be accepted?
>>
>> I'll try it out. This patch will have big ramifications for the typed
>> template haskell community.
>>
>> Matt
>>
>> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
>> <trupill at gmail.com> wrote:
>> >
>> > Dear all,
>> >
>> > We are trying to bring back `ImpredicativeTypes` into GHC by using the
>> ideas in the "Guarded Impredicative Polymorphism" paper [
>> https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
>> ].
>> >
>> > For now I have produced a first attempt, which lives in
>> https://gitlab.haskell.org/trupill/ghc. It would be great if those
>> interested in impredicative polymorphism could give it a try and see
>> whether it works as expected or not.
>> >
>> > The main idea behing "guarded impredicativity" is that you can infer an
>> impredicative instantiation for a type variable in a function call if you
>> have at least one given argument where that type variable appears under a
>> type constructor different from (->).
>> > For example, consider the call `(\x -> x) : ids`, where `ids :: [forall
>> a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] ->
>> [a]`, the variable `a` appears under the `[]` constructor and that second
>> argument is given, we are allowed to instantiate `a := forall a. a -> a`.
>> On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid
>> concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced
>> to instantiate `m` with a not-polymorphic type because at no point the
>> variable appears under a type constructor.
>> >
>> > Just for reference, the best to get a working clone is to follow these
>> steps:
>> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc
>> impredicative-ghc
>> > > cd impredicative-ghc
>> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
>> > > git fetch trupill
>> > > git checkout trupill master
>> >
>> > Thanks very much in advance,
>> > Alejandro
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/542bb6b5/attachment.html>

From matthewtpickering at gmail.com  Fri Jun 28 13:18:57 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 28 Jun 2019 14:18:57 +0100
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
 <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
Message-ID: <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>

I just tried it and it doesn't currently work.

[1 of 1] Compiling Id               ( Id.hs, interpreted )

Id.hs:14:7: error:
    • Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’
      Expected type: TExpQ (forall a. a -> a)
        Actual type: Q (TExp (a0 -> a0))
    • In the Template Haskell quotation [|| id ||]
      In the expression: [|| id ||]
      In an equation for ‘foo’: foo = [|| id ||]
   |
14 | foo = [|| id ||]
   |

Do you think you could perhaps take a look into fixing it?

PS: If you disable the testsuite on CI (so that the build passes) then
people can download and use the artefacts from your branch rather than
have to build the compiler from source.

Cheers,

Matt

On Fri, Jun 28, 2019 at 1:20 PM Alejandro Serrano Mena
<trupill at gmail.com> wrote:
>
> No, up to now the only changes are in the type checking of applications and variables.
> However, I guess that it would be possible to give [| id |] the type Code (forall a. a -> a) with a explicit type signature (the system always allows impredicative instantiation is explicitly marked), but without the annotation it would the usual type forall a. Code (a -> a).
>
> El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<matthewtpickering at gmail.com>) escribió:
>>
>> Have you modified how typed quotations are type checked? For example,
>> with your patch I would hope that
>>
>> [| id |] :: Code (forall a . a -> a)
>>
>> would be accepted?
>>
>> I'll try it out. This patch will have big ramifications for the typed
>> template haskell community.
>>
>> Matt
>>
>> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
>> <trupill at gmail.com> wrote:
>> >
>> > Dear all,
>> >
>> > We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/].
>> >
>> > For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not.
>> >
>> > The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->).
>> > For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor.
>> >
>> > Just for reference, the best to get a working clone is to follow these steps:
>> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc
>> > > cd impredicative-ghc
>> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
>> > > git fetch trupill
>> > > git checkout trupill master
>> >
>> > Thanks very much in advance,
>> > Alejandro
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ryan.gl.scott at gmail.com  Fri Jun 28 13:42:18 2019
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 28 Jun 2019 09:42:18 -0400
Subject: Guarded Impredicativity
Message-ID: <CADdQpRBw8RJefaTRy8P4p8b4vfq4P+-gB=eHFT26d6PscO3YGg@mail.gmail.com>

Would this permit explicit impredicativity as described in [1]? Simon
mentions in [1] that explicit impredicativity is easier to implement than
guarded impredicativity, although it's not clear to me if the latter would
imply the former.

Ryan S.
-----
[1] https://gitlab.haskell.org/ghc/ghc/issues/14859
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/effb55f7/attachment.html>

From trupill at gmail.com  Fri Jun 28 13:55:14 2019
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jun 2019 15:55:14 +0200
Subject: Guarded Impredicativity
In-Reply-To: <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
 <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
 <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>
Message-ID: <CAHnFXOtp+UZc84PcKPuffkarCh7G_6_VJpGh=oMALQXiiFxhZg@mail.gmail.com>

Hi,

El vie., 28 jun. 2019 a las 15:19, Matthew Pickering (<
matthewtpickering at gmail.com>) escribió:

> I just tried it and it doesn't currently work.
>
> [1 of 1] Compiling Id               ( Id.hs, interpreted )
>
> Id.hs:14:7: error:
>     • Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’
>       Expected type: TExpQ (forall a. a -> a)
>         Actual type: Q (TExp (a0 -> a0))
>     • In the Template Haskell quotation [|| id ||]
>       In the expression: [|| id ||]
>       In an equation for ‘foo’: foo = [|| id ||]
>    |
> 14 | foo = [|| id ||]
>    |
>
> Do you think you could perhaps take a look into fixing it?
>

I will give it a try.

>
> PS: If you disable the testsuite on CI (so that the build passes) then
> people can download and use the artefacts from your branch rather than
> have to build the compiler from source.
>

Is there an easy way to do this (or a tutorial), better in a way which
doesn't break the actual CI pipeline if this is finally merged?

Regards,
Alejandro

>
>
> On Fri, Jun 28, 2019 at 1:20 PM Alejandro Serrano Mena
> <trupill at gmail.com> wrote:
> >
> > No, up to now the only changes are in the type checking of applications
> and variables.
> > However, I guess that it would be possible to give [| id |] the type
> Code (forall a. a -> a) with a explicit type signature (the system always
> allows impredicative instantiation is explicitly marked), but without the
> annotation it would the usual type forall a. Code (a -> a).
> >
> > El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<
> matthewtpickering at gmail.com>) escribió:
> >>
> >> Have you modified how typed quotations are type checked? For example,
> >> with your patch I would hope that
> >>
> >> [| id |] :: Code (forall a . a -> a)
> >>
> >> would be accepted?
> >>
> >> I'll try it out. This patch will have big ramifications for the typed
> >> template haskell community.
> >>
> >> Matt
> >>
> >> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
> >> <trupill at gmail.com> wrote:
> >> >
> >> > Dear all,
> >> >
> >> > We are trying to bring back `ImpredicativeTypes` into GHC by using
> the ideas in the "Guarded Impredicative Polymorphism" paper [
> https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
> ].
> >> >
> >> > For now I have produced a first attempt, which lives in
> https://gitlab.haskell.org/trupill/ghc. It would be great if those
> interested in impredicative polymorphism could give it a try and see
> whether it works as expected or not.
> >> >
> >> > The main idea behing "guarded impredicativity" is that you can infer
> an impredicative instantiation for a type variable in a function call if
> you have at least one given argument where that type variable appears under
> a type constructor different from (->).
> >> > For example, consider the call `(\x -> x) : ids`, where `ids ::
> [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a]
> -> [a]`, the variable `a` appears under the `[]` constructor and that
> second argument is given, we are allowed to instantiate `a := forall a. a
> -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is
> monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are
> forced to instantiate `m` with a not-polymorphic type because at no point
> the variable appears under a type constructor.
> >> >
> >> > Just for reference, the best to get a working clone is to follow
> these steps:
> >> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc
> impredicative-ghc
> >> > > cd impredicative-ghc
> >> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> >> > > git fetch trupill
> >> > > git checkout trupill master
> >> >
> >> > Thanks very much in advance,
> >> > Alejandro
> >> >
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/821996d5/attachment.html>

From trupill at gmail.com  Fri Jun 28 13:57:55 2019
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jun 2019 15:57:55 +0200
Subject: Guarded Impredicativity
In-Reply-To: <CADdQpRBw8RJefaTRy8P4p8b4vfq4P+-gB=eHFT26d6PscO3YGg@mail.gmail.com>
References: <CADdQpRBw8RJefaTRy8P4p8b4vfq4P+-gB=eHFT26d6PscO3YGg@mail.gmail.com>
Message-ID: <CAHnFXOuNzz4XZwJoFu4sU_3M03bkhL+VX+hd_0-Y_arjGAR07Q@mail.gmail.com>

Yes, this is one of the features we would like to have. If you write down
the explicit instantiation of a function, we just take it, no questions
asked (well, the terms should still be type correct).
But writing out *every* single impredicative instantiation is really
tiresome, hence we are looking for "simple" ways to flow this information
around and alleavite a bit the burden.

El vie., 28 jun. 2019 a las 15:43, Ryan Scott (<ryan.gl.scott at gmail.com>)
escribió:

> Would this permit explicit impredicativity as described in [1]? Simon
> mentions in [1] that explicit impredicativity is easier to implement than
> guarded impredicativity, although it's not clear to me if the latter would
> imply the former.
>
> Ryan S.
> -----
> [1] https://gitlab.haskell.org/ghc/ghc/issues/14859
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/13bf8d95/attachment.html>

From trupill at gmail.com  Fri Jun 28 14:27:05 2019
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jun 2019 16:27:05 +0200
Subject: Guarded Impredicativity
In-Reply-To: <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
 <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
 <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>
Message-ID: <CAHnFXOvBuWy3vzuE=6o0umm74xuHQA_eJ5AxERm56OFccxJsJA@mail.gmail.com>

After having a quick look, I think it could be done easily in terms of type
checking. Alas, there's some code in TcSplice.hs which insists anyway on
having a quantifier-free type:

tcTExpTy :: TcType -> TcM TcType
tcTExpTy exp_ty
= do { unless (isTauTy exp_ty) $ addErr (err_msg exp_ty)
; ... }
where
err_msg ty
= vcat [ text "Illegal polytype:" <+> ppr ty
, text "The type of a Typed Template Haskell expression must" <+>
text "not have any quantification." ]

Does anybody have any pointers about why this restriction is in place?

Regards,
Alejandro

El vie., 28 jun. 2019 a las 15:19, Matthew Pickering (<
matthewtpickering at gmail.com>) escribió:

> I just tried it and it doesn't currently work.
>
> [1 of 1] Compiling Id               ( Id.hs, interpreted )
>
> Id.hs:14:7: error:
>     • Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’
>       Expected type: TExpQ (forall a. a -> a)
>         Actual type: Q (TExp (a0 -> a0))
>     • In the Template Haskell quotation [|| id ||]
>       In the expression: [|| id ||]
>       In an equation for ‘foo’: foo = [|| id ||]
>    |
> 14 | foo = [|| id ||]
>    |
>
> Do you think you could perhaps take a look into fixing it?
>
> PS: If you disable the testsuite on CI (so that the build passes) then
> people can download and use the artefacts from your branch rather than
> have to build the compiler from source.
>
> Cheers,
>
> Matt
>
> On Fri, Jun 28, 2019 at 1:20 PM Alejandro Serrano Mena
> <trupill at gmail.com> wrote:
> >
> > No, up to now the only changes are in the type checking of applications
> and variables.
> > However, I guess that it would be possible to give [| id |] the type
> Code (forall a. a -> a) with a explicit type signature (the system always
> allows impredicative instantiation is explicitly marked), but without the
> annotation it would the usual type forall a. Code (a -> a).
> >
> > El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<
> matthewtpickering at gmail.com>) escribió:
> >>
> >> Have you modified how typed quotations are type checked? For example,
> >> with your patch I would hope that
> >>
> >> [| id |] :: Code (forall a . a -> a)
> >>
> >> would be accepted?
> >>
> >> I'll try it out. This patch will have big ramifications for the typed
> >> template haskell community.
> >>
> >> Matt
> >>
> >> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
> >> <trupill at gmail.com> wrote:
> >> >
> >> > Dear all,
> >> >
> >> > We are trying to bring back `ImpredicativeTypes` into GHC by using
> the ideas in the "Guarded Impredicative Polymorphism" paper [
> https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
> ].
> >> >
> >> > For now I have produced a first attempt, which lives in
> https://gitlab.haskell.org/trupill/ghc. It would be great if those
> interested in impredicative polymorphism could give it a try and see
> whether it works as expected or not.
> >> >
> >> > The main idea behing "guarded impredicativity" is that you can infer
> an impredicative instantiation for a type variable in a function call if
> you have at least one given argument where that type variable appears under
> a type constructor different from (->).
> >> > For example, consider the call `(\x -> x) : ids`, where `ids ::
> [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a]
> -> [a]`, the variable `a` appears under the `[]` constructor and that
> second argument is given, we are allowed to instantiate `a := forall a. a
> -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is
> monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are
> forced to instantiate `m` with a not-polymorphic type because at no point
> the variable appears under a type constructor.
> >> >
> >> > Just for reference, the best to get a working clone is to follow
> these steps:
> >> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc
> impredicative-ghc
> >> > > cd impredicative-ghc
> >> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> >> > > git fetch trupill
> >> > > git checkout trupill master
> >> >
> >> > Thanks very much in advance,
> >> > Alejandro
> >> >
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190628/e1948728/attachment.html>

From matthewtpickering at gmail.com  Fri Jun 28 14:48:10 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 28 Jun 2019 15:48:10 +0100
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOvBuWy3vzuE=6o0umm74xuHQA_eJ5AxERm56OFccxJsJA@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
 <CALuQ0m_ZOmF89oM0HhfZ4w4gGjmSArfmL-CmfmxDuXhzr0Tc4A@mail.gmail.com>
 <CAHnFXOvDk+JyKb_rZrzGzyoFGyWQGDC_-fYY4hz-PUfeEb9j0g@mail.gmail.com>
 <CALuQ0m96rO+-V0nS41pat0wQY_yib6YAT2Tqm=t0qFneFUxoBw@mail.gmail.com>
 <CAHnFXOvBuWy3vzuE=6o0umm74xuHQA_eJ5AxERm56OFccxJsJA@mail.gmail.com>
Message-ID: <CALuQ0m839T=s2ZwD84_8NNFF8x_A4tf4K=zw0E5VvCvn3m8Z1Q@mail.gmail.com>

I believe the restriction is because of impredicativity..

My idea was to temporarily break the CI config whilst the tests don't
pass. I can make a MR for you if this would be acceptable.

Matt

On Fri, Jun 28, 2019 at 3:27 PM Alejandro Serrano Mena
<trupill at gmail.com> wrote:
>
> After having a quick look, I think it could be done easily in terms of type checking. Alas, there's some code in TcSplice.hs which insists anyway on having a quantifier-free type:
>
> tcTExpTy :: TcType -> TcM TcType
> tcTExpTy exp_ty
> = do { unless (isTauTy exp_ty) $ addErr (err_msg exp_ty)
> ; ... }
> where
> err_msg ty
> = vcat [ text "Illegal polytype:" <+> ppr ty
> , text "The type of a Typed Template Haskell expression must" <+>
> text "not have any quantification." ]
>
> Does anybody have any pointers about why this restriction is in place?
>
> Regards,
> Alejandro
>
> El vie., 28 jun. 2019 a las 15:19, Matthew Pickering (<matthewtpickering at gmail.com>) escribió:
>>
>> I just tried it and it doesn't currently work.
>>
>> [1 of 1] Compiling Id               ( Id.hs, interpreted )
>>
>> Id.hs:14:7: error:
>>     • Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’
>>       Expected type: TExpQ (forall a. a -> a)
>>         Actual type: Q (TExp (a0 -> a0))
>>     • In the Template Haskell quotation [|| id ||]
>>       In the expression: [|| id ||]
>>       In an equation for ‘foo’: foo = [|| id ||]
>>    |
>> 14 | foo = [|| id ||]
>>    |
>>
>> Do you think you could perhaps take a look into fixing it?
>>
>> PS: If you disable the testsuite on CI (so that the build passes) then
>> people can download and use the artefacts from your branch rather than
>> have to build the compiler from source.
>>
>> Cheers,
>>
>> Matt
>>
>> On Fri, Jun 28, 2019 at 1:20 PM Alejandro Serrano Mena
>> <trupill at gmail.com> wrote:
>> >
>> > No, up to now the only changes are in the type checking of applications and variables.
>> > However, I guess that it would be possible to give [| id |] the type Code (forall a. a -> a) with a explicit type signature (the system always allows impredicative instantiation is explicitly marked), but without the annotation it would the usual type forall a. Code (a -> a).
>> >
>> > El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<matthewtpickering at gmail.com>) escribió:
>> >>
>> >> Have you modified how typed quotations are type checked? For example,
>> >> with your patch I would hope that
>> >>
>> >> [| id |] :: Code (forall a . a -> a)
>> >>
>> >> would be accepted?
>> >>
>> >> I'll try it out. This patch will have big ramifications for the typed
>> >> template haskell community.
>> >>
>> >> Matt
>> >>
>> >> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
>> >> <trupill at gmail.com> wrote:
>> >> >
>> >> > Dear all,
>> >> >
>> >> > We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/].
>> >> >
>> >> > For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not.
>> >> >
>> >> > The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->).
>> >> > For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor.
>> >> >
>> >> > Just for reference, the best to get a working clone is to follow these steps:
>> >> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc
>> >> > > cd impredicative-ghc
>> >> > > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
>> >> > > git fetch trupill
>> >> > > git checkout trupill master
>> >> >
>> >> > Thanks very much in advance,
>> >> > Alejandro
>> >> >
>> >> > _______________________________________________
>> >> > ghc-devs mailing list
>> >> > ghc-devs at haskell.org
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From matthewtpickering at gmail.com  Sat Jun 29 09:57:09 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sat, 29 Jun 2019 10:57:09 +0100
Subject: Guarded Impredicativity
In-Reply-To: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
References: <CAHnFXOuHsuSg_tc-m_qhn=nH4EBoU+NSKq9vWx9Ny9wNqoX0-Q@mail.gmail.com>
Message-ID: <CALuQ0m87kPauTFrJSfp_VyNWa-WocMfn8sCv+8rnG-3_K0=q+Q@mail.gmail.com>

Here is a nix one liner to test the current state of the branch.

nix run -f https://github.com/mpickering/ghc-artefact-nix/archive//master.tar.gz
ghc-head-from -c ghc-head-from
https://gitlab.haskell.org/mpickering/ghc/-/jobs/114593/artifacts/raw/ghc-x86_64-fedora27-linux.tar.xz

On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
<trupill at gmail.com> wrote:
>
> Dear all,
>
> We are trying to bring back `ImpredicativeTypes` into GHC by using the ideas in the "Guarded Impredicative Polymorphism" paper [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/].
>
> For now I have produced a first attempt, which lives in https://gitlab.haskell.org/trupill/ghc. It would be great if those interested in impredicative polymorphism could give it a try and see whether it works as expected or not.
>
> The main idea behing "guarded impredicativity" is that you can infer an impredicative instantiation for a type variable in a function call if you have at least one given argument where that type variable appears under a type constructor different from (->).
> For example, consider the call `(\x -> x) : ids`, where `ids :: [forall a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] -> [a]`, the variable `a` appears under the `[]` constructor and that second argument is given, we are allowed to instantiate `a := forall a. a -> a`. On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced to instantiate `m` with a not-polymorphic type because at no point the variable appears under a type constructor.
>
> Just for reference, the best to get a working clone is to follow these steps:
> > git clone --recursive https://gitlab.haskell.org/ghc/ghc impredicative-ghc
> > cd impredicative-ghc
> > git remote add trupill git at gitlab.haskell.org:trupill/ghc.git
> > git fetch trupill
> > git checkout trupill master
>
> Thanks very much in advance,
> Alejandro
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at smart-cactus.org  Sat Jun 29 12:24:21 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 29 Jun 2019 08:24:21 -0400
Subject: Workflow question (changing codegen)
In-Reply-To: <CAMQQO3kyb_XB_RKY65YTatb9a52t_LJ2xymw9rcvWL0MK2EWjA@mail.gmail.com>
References: <CAMQQO3kyb_XB_RKY65YTatb9a52t_LJ2xymw9rcvWL0MK2EWjA@mail.gmail.com>
Message-ID: <CA11586E-E141-4B9F-AA4A-88285B8169F3@smart-cactus.org>

On June 28, 2019 5:09:45 AM EDT, "Ömer Sinan Ağacan" <omeragacan at gmail.com> wrote:
>Hi all,
>
>I'm currently going through this torturous process and I'm hoping that
>someone
>here will be able to help.
>
>I'm making changes in the codegen. My changes are currently buggy, and
>I need a
>working stage 1 compiler to be able to debug. Basically I need to build
>libraries using the branch my changes are based on, then build stage 1
>with my
>branch, so that I'll be able to build and run programs using stage 1
>that uses
>my codegen changes. The changes are compatible with the old codegen
>(i.e. no
>changes in calling conventions or anything like that) so this should
>work.
>
>Normally I do this
>
>    $ git checkout master
>    $ git distclean && ./boot && ./configure && make
>    $ git checkout my_branch
>    $ cd compiler; make 1
>
>This gives me stage 1 compiler that uses my buggy codegen changes, plus
>libraries built with the old and correct codegen.
>
>However the problem is I'm also adding a new file in my_branch, and the
>build
>system just doesn't register that fact, even after adding the line I
>added to
>compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix
>this
>that I could find was to run ./configure again, then run make for a few
>seconds
>at the top level, then do `make 1` in compiler/. Unfortunately even
>that doesn't
>work when the master branch and my_branch have different dates, because
>`make`
>in master branch produces a different version than the `make` in
>my_branch, so
>the interface files become incompatible.
>
>Anyone have any ideas on how to proceed here?
>
>Thanks,
>
>Ömer
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

In general I think it is wise to avoid switching branches in a tree you are actively developing in. The cost of switching both in the compilation time that it implies and the uncertain state that it leaves the tree in is in my opinion too high. It you want to compare your change against master I would recommend using two working directories. 


Cheers, 

- Ben 


From carter.schonwald at gmail.com  Sat Jun 29 15:48:14 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 29 Jun 2019 11:48:14 -0400
Subject: Why is NoExt inhabited?
In-Reply-To: <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>
References: <87sgrywvl3.fsf@smart-cactus.org>
 <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>
Message-ID: <CAHYVw0zYdgf2Q328dCh93E6m+ydPXkOtFx39Kck4zGbiqLJ2Yw@mail.gmail.com>

Phrased differently is a magic stand in for 0 ary sum and products ?

Or do you mean how n-ary sum and product are the same structure when n=1?

Forgot to cc list. Pardon the double send :)

On Mon, Jun 24, 2019 at 11:22 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I forget if I'm the contributor Ben mentions below, but regardless: NoExt
> is used in two separate ways within GHC. It's used both as the extension of
> a sum (new constructor) and the extension of a product (new field in a
> constructor). But the identity for sum is different than the identity for
> products. To me, it makes good sense for the NoExt used as a product
> extension (new field) to have the 1 trivial inhabitant (thus forming the
> identity for products), but the NoExt used as a sum extension (new
> constructor) to have 0 inhabitants (thus forming the identity for sums).
> Clearly, one of these will need a new name.
>
> Thanks,
> Richard
>
> > On Jun 24, 2019, at 4:57 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> >
> > Hi Shayan,
> >
> > During code review a contributor asked about a TTG extension point.
> > While answering his question I realized I didn't have a good explanation
> > for why NoExt is inhabited; as far as I can tell it should rather be
> > unhabited.
> >
> > If there is a reason for this then can you:
> >
> > 1. describe why this is so in #16863 [1]
> > 2. open an MR documenting the reason in Note [Trees that Grow].
> >
> > If not, perhaps we should consider changing it; the current state of
> > things is a bit awkward.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://gitlab.haskell.org/ghc/ghc/issues/16863
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190629/3da8ea3e/attachment.html>

From ml at stefansf.de  Sat Jun 29 18:05:57 2019
From: ml at stefansf.de (Stefan Schulze Frielinghaus)
Date: Sat, 29 Jun 2019 20:05:57 +0200
Subject: Vector registers assumed to be caller or callee-saved?
Message-ID: <20190629180557.GA8376@localhost.localdomain>

Hi all,

I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used
by the STG machine: are those assumed to be caller or callee-saved? Only for
the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in
includes/stg/MachRegs.h.  However, I cannot find any other place where those
macros are used.  AFAIK most C ABIs assume that vector registers are call
clobbered. Is this also the case for GHC?

Many thanks in advance,
Stefan

From rae at richarde.dev  Sat Jun 29 19:49:52 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 29 Jun 2019 15:49:52 -0400
Subject: Why is NoExt inhabited?
In-Reply-To: <CAHYVw0zYdgf2Q328dCh93E6m+ydPXkOtFx39Kck4zGbiqLJ2Yw@mail.gmail.com>
References: <87sgrywvl3.fsf@smart-cactus.org>
 <5688CC03-CFDE-4C8A-8FC6-8E0E87A3AD37@richarde.dev>
 <CAHYVw0zYdgf2Q328dCh93E6m+ydPXkOtFx39Kck4zGbiqLJ2Yw@mail.gmail.com>
Message-ID: <066C1183-8F18-44E3-995E-50410528C9B2@richarde.dev>



> On Jun 29, 2019, at 11:48 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> Phrased differently is a magic stand in for 0 ary sum and products ?
> 
> Or do you mean how n-ary sum and product are the same structure when n=1?

No -- I just mean that 0 (that is, Void) is the identity for sums and 1 (that is, Unit) is the identity for products. Sorry if this wasn't clear!

Richard

> 
> Forgot to cc list. Pardon the double send :)
> 
> On Mon, Jun 24, 2019 at 11:22 PM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I forget if I'm the contributor Ben mentions below, but regardless: NoExt is used in two separate ways within GHC. It's used both as the extension of a sum (new constructor) and the extension of a product (new field in a constructor). But the identity for sum is different than the identity for products. To me, it makes good sense for the NoExt used as a product extension (new field) to have the 1 trivial inhabitant (thus forming the identity for products), but the NoExt used as a sum extension (new constructor) to have 0 inhabitants (thus forming the identity for sums). Clearly, one of these will need a new name.
> 
> Thanks,
> Richard
> 
> > On Jun 24, 2019, at 4:57 PM, Ben Gamari <ben at smart-cactus.org <mailto:ben at smart-cactus.org>> wrote:
> > 
> > Hi Shayan,
> > 
> > During code review a contributor asked about a TTG extension point.
> > While answering his question I realized I didn't have a good explanation
> > for why NoExt is inhabited; as far as I can tell it should rather be
> > unhabited.
> > 
> > If there is a reason for this then can you:
> > 
> > 1. describe why this is so in #16863 [1]
> > 2. open an MR documenting the reason in Note [Trees that Grow].
> > 
> > If not, perhaps we should consider changing it; the current state of
> > things is a bit awkward.
> > 
> > Cheers,
> > 
> > - Ben
> > 
> > 
> > [1] https://gitlab.haskell.org/ghc/ghc/issues/16863 <https://gitlab.haskell.org/ghc/ghc/issues/16863>
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>

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

From rae at richarde.dev  Sat Jun 29 19:53:06 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 29 Jun 2019 15:53:06 -0400
Subject: Workflow question (changing codegen)
In-Reply-To: <CA11586E-E141-4B9F-AA4A-88285B8169F3@smart-cactus.org>
References: <CAMQQO3kyb_XB_RKY65YTatb9a52t_LJ2xymw9rcvWL0MK2EWjA@mail.gmail.com>
 <CA11586E-E141-4B9F-AA4A-88285B8169F3@smart-cactus.org>
Message-ID: <4D7733A6-9909-4117-AA4C-A57595EEB778@richarde.dev>

Just to pass on something that looks cool (I haven't tried it myself yet): git worktree. It seems git can hang several different checkouts of a repo in different directories. This seems far superior to my current habit of having many clones of ghc, sometimes going through machinations to get commits from one place to another. The documentation for git worktree seems quite approachable, so you might find it useful. I plan on using it in the future.

Richard

> On Jun 29, 2019, at 8:24 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> On June 28, 2019 5:09:45 AM EDT, "Ömer Sinan Ağacan" <omeragacan at gmail.com> wrote:
>> Hi all,
>> 
>> I'm currently going through this torturous process and I'm hoping that
>> someone
>> here will be able to help.
>> 
>> I'm making changes in the codegen. My changes are currently buggy, and
>> I need a
>> working stage 1 compiler to be able to debug. Basically I need to build
>> libraries using the branch my changes are based on, then build stage 1
>> with my
>> branch, so that I'll be able to build and run programs using stage 1
>> that uses
>> my codegen changes. The changes are compatible with the old codegen
>> (i.e. no
>> changes in calling conventions or anything like that) so this should
>> work.
>> 
>> Normally I do this
>> 
>>   $ git checkout master
>>   $ git distclean && ./boot && ./configure && make
>>   $ git checkout my_branch
>>   $ cd compiler; make 1
>> 
>> This gives me stage 1 compiler that uses my buggy codegen changes, plus
>> libraries built with the old and correct codegen.
>> 
>> However the problem is I'm also adding a new file in my_branch, and the
>> build
>> system just doesn't register that fact, even after adding the line I
>> added to
>> compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix
>> this
>> that I could find was to run ./configure again, then run make for a few
>> seconds
>> at the top level, then do `make 1` in compiler/. Unfortunately even
>> that doesn't
>> work when the master branch and my_branch have different dates, because
>> `make`
>> in master branch produces a different version than the `make` in
>> my_branch, so
>> the interface files become incompatible.
>> 
>> Anyone have any ideas on how to proceed here?
>> 
>> Thanks,
>> 
>> Ömer
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> In general I think it is wise to avoid switching branches in a tree you are actively developing in. The cost of switching both in the compilation time that it implies and the uncertain state that it leaves the tree in is in my opinion too high. It you want to compare your change against master I would recommend using two working directories. 
> 
> 
> Cheers, 
> 
> - Ben 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From klebinger.andreas at gmx.at  Sat Jun 29 23:23:27 2019
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Sun, 30 Jun 2019 01:23:27 +0200
Subject: Workflow question
Message-ID: <b1b3c86a-a818-3b9d-0a70-0fe1c58e9221@gmx.at>

I your situation I would just create a base commit with the (empty)
files you intend to add. Then you should not need to reconfigure to
build at least.

However it sounds like there is nothing stopping you from just building
stage1 with a working base commit, then freezing and iterating on stage2
and testing on non-ghc test cases.
It's what I usually do.





From sgraf1337 at gmail.com  Sun Jun 30 08:50:24 2019
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Sun, 30 Jun 2019 10:50:24 +0200
Subject: Workflow question (changing codegen)
In-Reply-To: <4D7733A6-9909-4117-AA4C-A57595EEB778@richarde.dev>
References: <CAMQQO3kyb_XB_RKY65YTatb9a52t_LJ2xymw9rcvWL0MK2EWjA@mail.gmail.com>
 <CA11586E-E141-4B9F-AA4A-88285B8169F3@smart-cactus.org>
 <4D7733A6-9909-4117-AA4C-A57595EEB778@richarde.dev>
Message-ID: <CAAS+=P8kp-X1VUm4fM5yNg2CRYMTU2JHrYom6m8iGsCbEou05g@mail.gmail.com>

Re: git worktree: That's the workflow I'm currently using. It has its
problems with submodules, see
https://stackoverflow.com/questions/31871888/what-goes-wrong-when-using-git-worktree-with-git-submodules.
But you can make it work with this git alias from the first answer:
https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L12.
Just go into your main checkout and do `git wtas ../T9876`. AFAIR it
interacts weirdly with MinGW's git or git for Windows, but nothing you
can't work around.

Anyway, I was hoping that one day hadrian will be smart enough to have a
build directory for each branch or something, so that I would only need one
checkout where I can switch between branches as needed. In the meantime,
`git wtas` does what I want.

Am Sa., 29. Juni 2019 um 21:53 Uhr schrieb Richard Eisenberg <
rae at richarde.dev>:

> Just to pass on something that looks cool (I haven't tried it myself yet):
> git worktree. It seems git can hang several different checkouts of a repo
> in different directories. This seems far superior to my current habit of
> having many clones of ghc, sometimes going through machinations to get
> commits from one place to another. The documentation for git worktree seems
> quite approachable, so you might find it useful. I plan on using it in the
> future.
>
> Richard
>
> > On Jun 29, 2019, at 8:24 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> >
> > On June 28, 2019 5:09:45 AM EDT, "Ömer Sinan Ağacan" <
> omeragacan at gmail.com> wrote:
> >> Hi all,
> >>
> >> I'm currently going through this torturous process and I'm hoping that
> >> someone
> >> here will be able to help.
> >>
> >> I'm making changes in the codegen. My changes are currently buggy, and
> >> I need a
> >> working stage 1 compiler to be able to debug. Basically I need to build
> >> libraries using the branch my changes are based on, then build stage 1
> >> with my
> >> branch, so that I'll be able to build and run programs using stage 1
> >> that uses
> >> my codegen changes. The changes are compatible with the old codegen
> >> (i.e. no
> >> changes in calling conventions or anything like that) so this should
> >> work.
> >>
> >> Normally I do this
> >>
> >>   $ git checkout master
> >>   $ git distclean && ./boot && ./configure && make
> >>   $ git checkout my_branch
> >>   $ cd compiler; make 1
> >>
> >> This gives me stage 1 compiler that uses my buggy codegen changes, plus
> >> libraries built with the old and correct codegen.
> >>
> >> However the problem is I'm also adding a new file in my_branch, and the
> >> build
> >> system just doesn't register that fact, even after adding the line I
> >> added to
> >> compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix
> >> this
> >> that I could find was to run ./configure again, then run make for a few
> >> seconds
> >> at the top level, then do `make 1` in compiler/. Unfortunately even
> >> that doesn't
> >> work when the master branch and my_branch have different dates, because
> >> `make`
> >> in master branch produces a different version than the `make` in
> >> my_branch, so
> >> the interface files become incompatible.
> >>
> >> Anyone have any ideas on how to proceed here?
> >>
> >> Thanks,
> >>
> >> Ömer
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> > In general I think it is wise to avoid switching branches in a tree you
> are actively developing in. The cost of switching both in the compilation
> time that it implies and the uncertain state that it leaves the tree in is
> in my opinion too high. It you want to compare your change against master I
> would recommend using two working directories.
> >
> >
> > Cheers,
> >
> > - Ben
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190630/2104c2f0/attachment.html>

From klebinger.andreas at gmx.at  Sun Jun 30 17:16:15 2019
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Sun, 30 Jun 2019 19:16:15 +0200
Subject: Vector registers assumed to be caller or callee-saved?
Message-ID: <1d25c0a4-b310-edf9-05c4-8aa7e43bccfe@gmx.at>

What you want is not the macro but this function:
https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs


whose results depend on the System ABI.

Cheers,
Andreas




> Hi all,
>
> I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used
> by the STG machine: are those assumed to be caller or callee-saved? Only for
> the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in
> includes/stg/MachRegs.h.  However, I cannot find any other place where those
> macros are used.  AFAIK most C ABIs assume that vector registers are call
> clobbered. Is this also the case for GHC?
>
> Many thanks in advance,
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190630/1216b509/attachment.html>

From ml at stefansf.de  Sun Jun 30 18:36:42 2019
From: ml at stefansf.de (Stefan Schulze Frielinghaus)
Date: Sun, 30 Jun 2019 20:36:42 +0200
Subject: Vector registers assumed to be caller or callee-saved?
In-Reply-To: <1d25c0a4-b310-edf9-05c4-8aa7e43bccfe@gmx.at>
References: <1d25c0a4-b310-edf9-05c4-8aa7e43bccfe@gmx.at>
Message-ID: <20190630183642.GA26175@localhost.localdomain>

But this only includes the NCG. What about the LLVM backend? For LLVM I
only found in compiler/llvmGen/LlvmCodeGen/CodeGen.hs function
definition getTrashRegs which makes use of function callerSaves which is
defined in includes/CodeGen.Platform.hs:

callerSaves :: GlobalReg -> Bool
#if defined(CALLER_SAVES_Base)
callerSaves BaseReg           = True
#endif
...
callerSaves _                 = False

There only for general-purpose and floating-point registers function
callerSaves may be defined to True. Thus, for XMMi, YMMi, and ZMMi
arguments the function evaluates to False.

Do I miss something for the LLVM backend? Maybe we just need to extend
the definition of callerSaves in order to respect vector registers, too?

Cheers,
Stefan


On Sun, Jun 30, 2019 at 07:16:15PM +0200, Andreas Klebinger wrote:
> What you want is not the macro but this function:
> https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs
>
>
> whose results depend on the System ABI.
>
> Cheers,
> Andreas
>
>
>
>
> > Hi all,
> >
> > I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used
> > by the STG machine: are those assumed to be caller or callee-saved? Only for
> > the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in
> > includes/stg/MachRegs.h.  However, I cannot find any other place where those
> > macros are used.  AFAIK most C ABIs assume that vector registers are call
> > clobbered. Is this also the case for GHC?
> >
> > Many thanks in advance,
> > Stefan
> >

From klebinger.andreas at gmx.at  Sun Jun 30 21:01:28 2019
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Sun, 30 Jun 2019 23:01:28 +0200
Subject: Vector registers assumed to be caller or callee-saved?
In-Reply-To: <20190630183642.GA26175@localhost.localdomain>
References: <1d25c0a4-b310-edf9-05c4-8aa7e43bccfe@gmx.at>
 <20190630183642.GA26175@localhost.localdomain>
Message-ID: <93d69924-dc4f-6e2a-f341-002ec1ea6048@gmx.at>

It is my understanding that we only communicate the calling convention
to be used via LLVM IR
  and LLVM handles generation of the save/restore instructions required
for the call.

So indeed neither the macro nor this function would be used there. But I
gathered that just by skimming
the LLVM code at times so maybe I got something wrong there.


Stefan Schulze Frielinghaus schrieb am 30.06.2019 um 20:36:
> But this only includes the NCG. What about the LLVM backend? For LLVM I
> only found in compiler/llvmGen/LlvmCodeGen/CodeGen.hs function
> definition getTrashRegs which makes use of function callerSaves which is
> defined in includes/CodeGen.Platform.hs:
>
> callerSaves :: GlobalReg -> Bool
> #if defined(CALLER_SAVES_Base)
> callerSaves BaseReg           = True
> #endif
> ...
> callerSaves _                 = False
>
> There only for general-purpose and floating-point registers function
> callerSaves may be defined to True. Thus, for XMMi, YMMi, and ZMMi
> arguments the function evaluates to False.
>
> Do I miss something for the LLVM backend? Maybe we just need to extend
> the definition of callerSaves in order to respect vector registers, too?
>
> Cheers,
> Stefan
>
>
> On Sun, Jun 30, 2019 at 07:16:15PM +0200, Andreas Klebinger wrote:
>> What you want is not the macro but this function:
>> https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs
>>
>>
>> whose results depend on the System ABI.
>>
>> Cheers,
>> Andreas
>>
>>
>>
>>
>>> Hi all,
>>>
>>> I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used
>>> by the STG machine: are those assumed to be caller or callee-saved? Only for
>>> the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in
>>> includes/stg/MachRegs.h.  However, I cannot find any other place where those
>>> macros are used.  AFAIK most C ABIs assume that vector registers are call
>>> clobbered. Is this also the case for GHC?
>>>
>>> Many thanks in advance,
>>> Stefan
>>>