From ben at smart-cactus.org  Tue Jan  1 11:32:28 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 01 Jan 2019 06:32:28 -0500
Subject: Welcome to GitLab!
In-Reply-To: <1546298853.4750.63.camel@jeltsch.info>
References: <87a7krscvf.fsf@smart-cactus.org>
 <1546298853.4750.63.camel@jeltsch.info>
Message-ID: <DBC6627D-78DB-415E-88E2-A8E76AAB20E4@smart-cactus.org>

On December 31, 2018 6:27:33 PM EST, Wolfgang Jeltsch <wolfgang-it at jeltsch.info> wrote:
>Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari:
>> In the meantime, users of Trac should check and possibly update the
>> email address associated with their account [1].  This address will
>be
>> used to correlate Trac users with their GitLab equivalents so the
>> correctness of this address will be important in preserving
>> attribution information during the Trac import.
>> 
>> [1] https://ghc.haskell.org/trac/ghc/prefs
>
>Will this correlation also work if I don’t have a GitLab account at the
>time of migration but later will get a GitLab account that uses the e-
>mail address I have on Trac?
>

When the Trac migration is carried out new GitLab accounts will be created for Trac users who have not yet created an account. You will be able to request a password reset to gain access to this account. 

Cheers, 

- Ben 



From wolfgang-it at jeltsch.info  Tue Jan  1 18:47:39 2019
From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch)
Date: Tue, 01 Jan 2019 20:47:39 +0200
Subject: Welcome to GitLab!
In-Reply-To: <DBC6627D-78DB-415E-88E2-A8E76AAB20E4@smart-cactus.org>
References: <87a7krscvf.fsf@smart-cactus.org>
 <1546298853.4750.63.camel@jeltsch.info>
 <DBC6627D-78DB-415E-88E2-A8E76AAB20E4@smart-cactus.org>
Message-ID: <1546368459.4750.72.camel@jeltsch.info>

Am Dienstag, den 01.01.2019, 06:32 -0500 schrieb Ben Gamari:
> On December 31, 2018 6:27:33 PM EST, Wolfgang Jeltsch:
> > 
> > Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari:
> > > 
> > > In the meantime, users of Trac should check and possibly update
> > > the email address associated with their account [1].  This address
> > > will be used to correlate Trac users with their GitLab equivalents
> > > so the correctness of this address will be important in preserving
> > > attribution information during the Trac import.
> > > 
> > > [1] https://ghc.haskell.org/trac/ghc/prefs
> >
> > Will this correlation also work if I don’t have a GitLab account at
> > the time of migration but later will get a GitLab account that uses
> > the e-mail address I have on Trac?
> 
> When the Trac migration is carried out new GitLab accounts will be
> created for Trac users who have not yet created an account. You will
> be able to request a password reset to gain access to this account.

Hmm. I’d like to have a GitLab account linked to my GitHub account
(login via GitHub credentials) rather than an independent GitLab
account. What if I create a GitHub-linked GitLab account before the
migration? Will this account be used for my Trac stuff in case my
GitHub(!) e-mail address is the same as my Trac e-mail address?

All the best,
Wolfgang

From ben at smart-cactus.org  Tue Jan  1 20:04:45 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 01 Jan 2019 15:04:45 -0500
Subject: Welcome to GitLab!
In-Reply-To: <1546368459.4750.72.camel@jeltsch.info>
References: <87a7krscvf.fsf@smart-cactus.org>
 <1546298853.4750.63.camel@jeltsch.info>
 <DBC6627D-78DB-415E-88E2-A8E76AAB20E4@smart-cactus.org>
 <1546368459.4750.72.camel@jeltsch.info>
Message-ID: <875zv8p2jr.fsf@smart-cactus.org>

Wolfgang Jeltsch <wolfgang-it at jeltsch.info> writes:

> Am Dienstag, den 01.01.2019, 06:32 -0500 schrieb Ben Gamari:
>> 
>> When the Trac migration is carried out new GitLab accounts will be
>> created for Trac users who have not yet created an account. You will
>> be able to request a password reset to gain access to this account.
>
> Hmm. I’d like to have a GitLab account linked to my GitHub account
> (login via GitHub credentials) rather than an independent GitLab
> account. What if I create a GitHub-linked GitLab account before the
> migration? Will this account be used for my Trac stuff in case my
> GitHub(!) e-mail address is the same as my Trac e-mail address?
>
I'm pretty certain it will although I have not verified this yet. I'll
make a note to check.

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/20190101/dceb9189/attachment.sig>

From wolfgang-it at jeltsch.info  Tue Jan  1 21:58:35 2019
From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch)
Date: Tue, 01 Jan 2019 23:58:35 +0200
Subject: Welcome to GitLab!
In-Reply-To: <875zv8p2jr.fsf@smart-cactus.org>
References: <87a7krscvf.fsf@smart-cactus.org>
 <1546298853.4750.63.camel@jeltsch.info>
 <DBC6627D-78DB-415E-88E2-A8E76AAB20E4@smart-cactus.org>
 <1546368459.4750.72.camel@jeltsch.info> <875zv8p2jr.fsf@smart-cactus.org>
Message-ID: <1546379915.4750.93.camel@jeltsch.info>

Am Dienstag, den 01.01.2019, 15:04 -0500 schrieb Ben Gamari:
> Wolfgang Jeltsch <wolfgang-it at jeltsch.info> writes:
> > What if I create a GitHub-linked GitLab account before the 
> > migration? Will this account be used for my Trac stuff in case my 
> > GitHub(!) e-mail address is the same as my Trac e-mail address?
> 
> I'm pretty certain it will although I have not verified this yet. I'll
> make a note to check.

Thanks a lot.

All the best,
Wolfgang

From antonxue1572 at gmail.com  Wed Jan  2 04:31:54 2019
From: antonxue1572 at gmail.com (Anton Xue)
Date: Tue, 1 Jan 2019 23:31:54 -0500
Subject: Getting ghc/Main.hs to import modules
Message-ID: <CAEM8hpz1nZqU88H_8Cp6ZdDdO4mT58=XaF9QhXjedvfQj1JbVA@mail.gmail.com>

Hey all,

I want to make modifications to a custom version of ghc/Main.hs that
depends on packages not natively shipped with GHC 8.2.2.

In short, I want to be able to write "import Network" (
http://hackage.haskell.org/package/network-2.8.0.0) in ghc/Main.hs and then
build GHC from source. However, I am running into some problems, and here
is what I have attempted based on the Building/Modifying page (
https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying):

1. I downloaded a copy of the network package and placed it in
libraries/network.
2. I added an entry to the packages file for library/network, and used
dashes for all the other entries.
3. perl boot
4. I modified ghc.mk and placed libraries/network as the first
PACKAGES_STAGE1 append right before ghc-prim
5. make -j5

The build then fails complaining that:

ghc/Main.hs:77:8: error:
    Could not find module ‘Network’
    Use -v to see a list of the files searched for.
   |
77 | import Network


A similar problem also appears when I replace "import Network" with "import
System.Console.Haskeline", which is strange considering that haskeline was
shipped with GHC 8.2.2. However, other imports such as "import
System.CPUTime", which was defined in base, do not raise this error.
Otherwise GHC builds fine with no errors.

I am wondering what I should do to solve this issue.


Thank you,

Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190101/4431003f/attachment.html>

From carter.schonwald at gmail.com  Thu Jan  3 19:34:27 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 3 Jan 2019 14:34:27 -0500
Subject: Getting ghc/Main.hs to import modules
In-Reply-To: <CAEM8hpz1nZqU88H_8Cp6ZdDdO4mT58=XaF9QhXjedvfQj1JbVA@mail.gmail.com>
References: <CAEM8hpz1nZqU88H_8Cp6ZdDdO4mT58=XaF9QhXjedvfQj1JbVA@mail.gmail.com>
Message-ID: <CAHYVw0z_xVmQee8TGqPkzuR1W7g-qN830jhCUAoH8FZOtfyD0g@mail.gmail.com>

you will need to edit the associated cabal file

On Wed, Jan 2, 2019 at 10:49 PM Anton Xue <antonxue1572 at gmail.com> wrote:

> Hey all,
>
> I want to make modifications to a custom version of ghc/Main.hs that
> depends on packages not natively shipped with GHC 8.2.2.
>
> In short, I want to be able to write "import Network" (
> http://hackage.haskell.org/package/network-2.8.0.0) in ghc/Main.hs and
> then build GHC from source. However, I am running into some problems, and
> here is what I have attempted based on the Building/Modifying page (
> https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying):
>
> 1. I downloaded a copy of the network package and placed it in
> libraries/network.
> 2. I added an entry to the packages file for library/network, and used
> dashes for all the other entries.
> 3. perl boot
> 4. I modified ghc.mk and placed libraries/network as the first
> PACKAGES_STAGE1 append right before ghc-prim
> 5. make -j5
>
> The build then fails complaining that:
>
> ghc/Main.hs:77:8: error:
>     Could not find module ‘Network’
>     Use -v to see a list of the files searched for.
>    |
> 77 | import Network
>
>
> A similar problem also appears when I replace "import Network" with
> "import System.Console.Haskeline", which is strange considering that
> haskeline was shipped with GHC 8.2.2. However, other imports such as
> "import System.CPUTime", which was defined in base, do not raise this
> error. Otherwise GHC builds fine with no errors.
>
> I am wondering what I should do to solve this issue.
>
>
> Thank you,
>
> Anton
>
>
> _______________________________________________
> 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/20190103/8c779311/attachment.html>

From rae at cs.brynmawr.edu  Thu Jan  3 21:35:36 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 3 Jan 2019 16:35:36 -0500
Subject: GitLab cross-posting to Trac?
Message-ID: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>

Hi devs,

With our new GitLab workflow, will commit messages still be posted to Issues (once the migration is complete)? That's been really useful with Trac.

Thanks,
Richard

From v.dijk.bas at gmail.com  Fri Jan  4 00:22:34 2019
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Fri, 4 Jan 2019 01:22:34 +0100
Subject: Failure to catch C++ exception in Haskell on OS X
Message-ID: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>

Dear GHC Devs,

I'm debugging an issue in our haskell-opencv library where a C++ exception
that is thrown by the OpenCV C++ library isn't caught by the C++
try...catch block we have inlined in our Haskell code using inline-c-cpp.
This results in the process terminating by SIGABRT.

Note that this only happens on OS X. In Linux the exception is caught
correctly.

I wrote a minimal isolated test case (which doesn't use OpenCV) at:

  https://github.com/basvandijk/darwin-cxx-exception-bug

I wrote some instructions in the README on how to reproduce this and
included some debugging notes.

I'm not sure the bug is caused by a mis-configuration in my code or if it's
a bug in nixpkgs, Cabal or GHC. Any idea what could be causing this?

Bas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190104/33febb6f/attachment.html>

From antonxue1572 at gmail.com  Fri Jan  4 02:18:58 2019
From: antonxue1572 at gmail.com (Anton Xue)
Date: Thu, 3 Jan 2019 21:18:58 -0500
Subject: Getting ghc/Main.hs to import modules
In-Reply-To: <CAHYVw0z_xVmQee8TGqPkzuR1W7g-qN830jhCUAoH8FZOtfyD0g@mail.gmail.com>
References: <CAEM8hpz1nZqU88H_8Cp6ZdDdO4mT58=XaF9QhXjedvfQj1JbVA@mail.gmail.com>
 <CAHYVw0z_xVmQee8TGqPkzuR1W7g-qN830jhCUAoH8FZOtfyD0g@mail.gmail.com>
Message-ID: <CAEM8hpyBX5gHNZfbRJG6BXyqJ4dsoqFx=WWk-WbLUeqPuPdODA@mail.gmail.com>

Hey Carter,

Thanks for getting back to me.

I've tried sticking a "network == 2.8.0.0" dependency into different
combinations of the following files:

- compiler/ghc.cabal.in
- ghc/ghc-bin.cabal.in
- utils/ghc-cabal/ghc-cabal.cabal
- utils/ghc-pkg-ghc-pkg.cabal


In addition, I've also tried adding a "-ilibraries/network" into
utils/ghc-cabal/ghc.mk

At the moment, there is evidently some progress, since it fails with:


Configuring ghc-pkg-6.9...
Configuring ghc-8.2.2...
ghc-cabal: Encountered missing dependencies:
network ==2.8.0.0
utils/ghc-pkg/ghc.mk:64: recipe for target 'utils/ghc-pkg/dist/
package-data.mk' failed
make[1]: *** [utils/ghc-pkg/dist/package-data.mk] Error 1
make[1]: *** Waiting for unfinished jobs....
ghc-cabal: Encountered missing dependencies:
network ==2.8.0.0
compiler/ghc.mk:587: recipe for target 'compiler/stage1/package-data.mk'
failed
make[1]: *** [compiler/stage1/package-data.mk] Error 1
Makefile:122: recipe for target 'all' failed
make: *** [all] Error 2


However, from here I'm stuck.

The network package that already exists on my system is also 2.8.0.0.


Anton

On Thu, Jan 3, 2019 at 2:34 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> you will need to edit the associated cabal file
>
> On Wed, Jan 2, 2019 at 10:49 PM Anton Xue <antonxue1572 at gmail.com> wrote:
>
>> Hey all,
>>
>> I want to make modifications to a custom version of ghc/Main.hs that
>> depends on packages not natively shipped with GHC 8.2.2.
>>
>> In short, I want to be able to write "import Network" (
>> http://hackage.haskell.org/package/network-2.8.0.0) in ghc/Main.hs and
>> then build GHC from source. However, I am running into some problems, and
>> here is what I have attempted based on the Building/Modifying page (
>> https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying):
>>
>> 1. I downloaded a copy of the network package and placed it in
>> libraries/network.
>> 2. I added an entry to the packages file for library/network, and used
>> dashes for all the other entries.
>> 3. perl boot
>> 4. I modified ghc.mk and placed libraries/network as the first
>> PACKAGES_STAGE1 append right before ghc-prim
>> 5. make -j5
>>
>> The build then fails complaining that:
>>
>> ghc/Main.hs:77:8: error:
>>     Could not find module ‘Network’
>>     Use -v to see a list of the files searched for.
>>    |
>> 77 | import Network
>>
>>
>> A similar problem also appears when I replace "import Network" with
>> "import System.Console.Haskeline", which is strange considering that
>> haskeline was shipped with GHC 8.2.2. However, other imports such as
>> "import System.CPUTime", which was defined in base, do not raise this
>> error. Otherwise GHC builds fine with no errors.
>>
>> I am wondering what I should do to solve this issue.
>>
>>
>> Thank you,
>>
>> Anton
>>
>>
>> _______________________________________________
>> 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/20190103/638905b6/attachment.html>

From m at tweag.io  Fri Jan  4 13:11:38 2019
From: m at tweag.io (Boespflug, Mathieu)
Date: Fri, 4 Jan 2019 14:11:38 +0100
Subject: Type family equation violates injectivity?
In-Reply-To: <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
Message-ID: <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>

Hi Carter,

thanks for looking into this. We were initially surprised to see a breaking
change in a point release, but no biggy. It's pretty hard to offer strong
stability guarantees without automated tooling to catch this kind of thing,
and these things happen. We'll patch up HaskellR shortly.

Best,


On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> To be clear : I’m annoyed with myself that this impacted a package that
> depends on vector, but this does seem to be the case that the newest bug
> fix release for vector actually revealed a broken design for the vector
> instances / data types in the inline-r package.
>
> To;dr — I suggest patching inline-r to remove the s parameter in its
> immutable vector data types
>
> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> so i took a look .. (also the inline-r devs seem to have done a hackage
>> revision so you wont hit that issue in your current setup if you do a cabal
>> update ..)
>> and it seems like the type definitions in inline-r are kinda bogus  and
>> you should get them patched ...
>>
>> the MVector type class, and related type families, all assume your
>> mutable type has the last two arguments as the io/state token and then the
>> element type
>>
>> eg
>> basicLength :: v s a -> Int
>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>
>>
>> i looked at
>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>> and
>>
>>
>>
>> as a point of grounding this chat
>> the injective type familly in question is defined by the follwoing
>>
>>
>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>
>> anyways, it looks like the Pure / immutable vector data type in inline-r
>> has a spurious state token argument in its definition that shouldn't be
>> there, OR there need to be two "s" params in inline-r instead of the one
>>
>> heres the full code i linked to in question
>>
>>
>> -- | Mutable R vector. Represented in memory with the same header as
>> 'SEXP'
>>
>> -- nodes. The second type parameter is phantom, reflecting at the type
>> level the
>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and
>> the
>> -- representation type are related via 'ElemRep'.
>> data MVector s ty a = MVector
>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>> , mvectorOffset :: {-# UNPACK #-} !Int32
>> , mvectorLength :: {-# UNPACK #-} !Int32
>> }
>> -- | Internal wrapper type for reflection. First type parameter is the
>> reified
>> -- type to reflect.
>> newtype W t ty s a = W { unW :: MVector s ty a }
>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) a
>> where
>>
>> data Vector s (ty :: SEXPTYPE) a = Vector
>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>> }
>>
>>
>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>> Anyways, the fix here is to remove the s param from the Pure version of W
>> and "Sexp Vector"
>>
>>
>>
>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> were you using the same version of vector in both setups?
>>>
>>> in the most recent  vector release  we made mutable type family
>>> injective in the vector package for ghc's that support it ...
>>>
>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <djsamperi at gmail.com>
>>> wrote:
>>>
>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
>>>> I get the error "Type family equation violates injectivity annotation,"
>>>> and
>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>> the lack of injectivity (I suppose).
>>>>
>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under
>>>> Ubuntu) does not have this problem (it has other problems).
>>>>
>>>> Has something changed in the latest version of the compiler that might
>>>> cause this? Possible work-around?
>>>>
>>>> FYI, the line that triggers the error is:
>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>
>>>> The variable that cannot be inferred is 's'.
>>>>
>>>> Thanks,
>>>> Dominick
>>>> _______________________________________________
>>>> 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/20190104/9eaba83d/attachment.html>

From ggreif at gmail.com  Fri Jan  4 13:15:40 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Fri, 4 Jan 2019 14:15:40 +0100
Subject: Failure to catch C++ exception in Haskell on OS X
In-Reply-To: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
References: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
Message-ID: <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>

Hi Bas,

maybe some DWARF unwind tables are not correctly installed in OS X?

Do intra-C++ exception catching work in your example?

Cheers,

    Gabor

On 1/4/19, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> Dear GHC Devs,
>
> I'm debugging an issue in our haskell-opencv library where a C++ exception
> that is thrown by the OpenCV C++ library isn't caught by the C++
> try...catch block we have inlined in our Haskell code using inline-c-cpp.
> This results in the process terminating by SIGABRT.
>
> Note that this only happens on OS X. In Linux the exception is caught
> correctly.
>
> I wrote a minimal isolated test case (which doesn't use OpenCV) at:
>
>   https://github.com/basvandijk/darwin-cxx-exception-bug
>
> I wrote some instructions in the README on how to reproduce this and
> included some debugging notes.
>
> I'm not sure the bug is caused by a mis-configuration in my code or if it's
> a bug in nixpkgs, Cabal or GHC. Any idea what could be causing this?
>
> Bas
>

From carter.schonwald at gmail.com  Fri Jan  4 14:23:08 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 4 Jan 2019 09:23:08 -0500
Subject: Type family equation violates injectivity?
In-Reply-To: <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
Message-ID: <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>

Yeah, I later found it impacted one of my own pieces of code too, in that I
needed to make still further type families injective.

I do think that a lot of vectors current module structure reflects a desire
for injectivity coupled with historical a lack of mechanism for
guaranteeing it.

Mess up on my part for sure.  :)

On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:

> Hi Carter,
>
> thanks for looking into this. We were initially surprised to see a
> breaking change in a point release, but no biggy. It's pretty hard to offer
> strong stability guarantees without automated tooling to catch this kind of
> thing, and these things happen. We'll patch up HaskellR shortly.
>
> Best,
>
>
> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> To be clear : I’m annoyed with myself that this impacted a package that
>> depends on vector, but this does seem to be the case that the newest bug
>> fix release for vector actually revealed a broken design for the vector
>> instances / data types in the inline-r package.
>>
>> To;dr — I suggest patching inline-r to remove the s parameter in its
>> immutable vector data types
>>
>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> so i took a look .. (also the inline-r devs seem to have done a hackage
>>> revision so you wont hit that issue in your current setup if you do a cabal
>>> update ..)
>>> and it seems like the type definitions in inline-r are kinda bogus  and
>>> you should get them patched ...
>>>
>>> the MVector type class, and related type families, all assume your
>>> mutable type has the last two arguments as the io/state token and then the
>>> element type
>>>
>>> eg
>>> basicLength :: v s a -> Int
>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>
>>>
>>> i looked at
>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>> and
>>>
>>>
>>>
>>> as a point of grounding this chat
>>> the injective type familly in question is defined by the follwoing
>>>
>>>
>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>
>>> anyways, it looks like the Pure / immutable vector data type in inline-r
>>> has a spurious state token argument in its definition that shouldn't be
>>> there, OR there need to be two "s" params in inline-r instead of the one
>>>
>>> heres the full code i linked to in question
>>>
>>>
>>> -- | Mutable R vector. Represented in memory with the same header as
>>> 'SEXP'
>>>
>>> -- nodes. The second type parameter is phantom, reflecting at the type
>>> level the
>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and
>>> the
>>> -- representation type are related via 'ElemRep'.
>>> data MVector s ty a = MVector
>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>> }
>>> -- | Internal wrapper type for reflection. First type parameter is the
>>> reified
>>> -- type to reflect.
>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty)
>>> a where
>>>
>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
>>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>> }
>>>
>>>
>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>> Anyways, the fix here is to remove the s param from the Pure version of
>>> W and "Sexp Vector"
>>>
>>>
>>>
>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> were you using the same version of vector in both setups?
>>>>
>>>> in the most recent  vector release  we made mutable type family
>>>> injective in the vector package for ghc's that support it ...
>>>>
>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <djsamperi at gmail.com>
>>>> wrote:
>>>>
>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
>>>>> I get the error "Type family equation violates injectivity
>>>>> annotation," and
>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>> the lack of injectivity (I suppose).
>>>>>
>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under
>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>
>>>>> Has something changed in the latest version of the compiler that might
>>>>> cause this? Possible work-around?
>>>>>
>>>>> FYI, the line that triggers the error is:
>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>
>>>>> The variable that cannot be inferred is 's'.
>>>>>
>>>>> Thanks,
>>>>> Dominick
>>>>> _______________________________________________
>>>>> 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/20190104/e6d1b0bd/attachment.html>

From carter.schonwald at gmail.com  Fri Jan  4 14:31:26 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 4 Jan 2019 09:31:26 -0500
Subject: Type family equation violates injectivity?
In-Reply-To: <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
 <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
Message-ID: <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>

Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
bump and make the bug fix bump version unbuildable.

Would this help matters ?

On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Yeah, I later found it impacted one of my own pieces of code too, in that
> I needed to make still further type families injective.
>
> I do think that a lot of vectors current module structure reflects a
> desire for injectivity coupled with historical a lack of mechanism for
> guaranteeing it.
>
> Mess up on my part for sure.  :)
>
> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:
>
>> Hi Carter,
>>
>> thanks for looking into this. We were initially surprised to see a
>> breaking change in a point release, but no biggy. It's pretty hard to offer
>> strong stability guarantees without automated tooling to catch this kind of
>> thing, and these things happen. We'll patch up HaskellR shortly.
>>
>> Best,
>>
>>
>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> To be clear : I’m annoyed with myself that this impacted a package that
>>> depends on vector, but this does seem to be the case that the newest bug
>>> fix release for vector actually revealed a broken design for the vector
>>> instances / data types in the inline-r package.
>>>
>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>> immutable vector data types
>>>
>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> so i took a look .. (also the inline-r devs seem to have done a hackage
>>>> revision so you wont hit that issue in your current setup if you do a cabal
>>>> update ..)
>>>> and it seems like the type definitions in inline-r are kinda bogus  and
>>>> you should get them patched ...
>>>>
>>>> the MVector type class, and related type families, all assume your
>>>> mutable type has the last two arguments as the io/state token and then the
>>>> element type
>>>>
>>>> eg
>>>> basicLength :: v s a -> Int
>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>>
>>>>
>>>> i looked at
>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>>> and
>>>>
>>>>
>>>>
>>>> as a point of grounding this chat
>>>> the injective type familly in question is defined by the follwoing
>>>>
>>>>
>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>>
>>>> anyways, it looks like the Pure / immutable vector data type in
>>>> inline-r has a spurious state token argument in its definition that
>>>> shouldn't be there, OR there need to be two "s" params in inline-r instead
>>>> of the one
>>>>
>>>> heres the full code i linked to in question
>>>>
>>>>
>>>> -- | Mutable R vector. Represented in memory with the same header as
>>>> 'SEXP'
>>>>
>>>> -- nodes. The second type parameter is phantom, reflecting at the type
>>>> level the
>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and
>>>> the
>>>> -- representation type are related via 'ElemRep'.
>>>> data MVector s ty a = MVector
>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>>> }
>>>> -- | Internal wrapper type for reflection. First type parameter is the
>>>> reified
>>>> -- type to reflect.
>>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty)
>>>> a where
>>>>
>>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
>>>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>>> }
>>>>
>>>>
>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>> Anyways, the fix here is to remove the s param from the Pure version of
>>>> W and "Sexp Vector"
>>>>
>>>>
>>>>
>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> were you using the same version of vector in both setups?
>>>>>
>>>>> in the most recent  vector release  we made mutable type family
>>>>> injective in the vector package for ghc's that support it ...
>>>>>
>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <djsamperi at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
>>>>>> I get the error "Type family equation violates injectivity
>>>>>> annotation," and
>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>>> the lack of injectivity (I suppose).
>>>>>>
>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under
>>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>>
>>>>>> Has something changed in the latest version of the compiler that might
>>>>>> cause this? Possible work-around?
>>>>>>
>>>>>> FYI, the line that triggers the error is:
>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>
>>>>>> The variable that cannot be inferred is 's'.
>>>>>>
>>>>>> Thanks,
>>>>>> Dominick
>>>>>> _______________________________________________
>>>>>> 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/20190104/cbccbd4a/attachment-0001.html>

From alexander.vershilov at gmail.com  Fri Jan  4 14:59:22 2019
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Fri, 4 Jan 2019 17:59:22 +0300
Subject: Type family equation violates injectivity?
In-Reply-To: <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
 <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
 <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>
Message-ID: <CAO-1Pb4EH-CMdKO4J_exQUKh8rhyPiwi1+TqKSWB5eyxQ66wiQ@mail.gmail.com>

For inline-r we have added a revision that sets upper limit, so now hackage
and stackage should both be happy. I'm not sure if any Linux distribution
provides inline-r as a package but that should be normal situation for
them. Next version will either set lower dependency boundary or will keep a
code that will run with both APIs. So from my perspective any solution
(even keeping things as-is) will be ok.

On Fri, Jan 4, 2019, 17:31 Carter Schonwald <carter.schonwald at gmail.com
wrote:

> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
> bump and make the bug fix bump version unbuildable.
>
> Would this help matters ?
>
> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Yeah, I later found it impacted one of my own pieces of code too, in that
>> I needed to make still further type families injective.
>>
>> I do think that a lot of vectors current module structure reflects a
>> desire for injectivity coupled with historical a lack of mechanism for
>> guaranteeing it.
>>
>> Mess up on my part for sure.  :)
>>
>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:
>>
>>> Hi Carter,
>>>
>>> thanks for looking into this. We were initially surprised to see a
>>> breaking change in a point release, but no biggy. It's pretty hard to offer
>>> strong stability guarantees without automated tooling to catch this kind of
>>> thing, and these things happen. We'll patch up HaskellR shortly.
>>>
>>> Best,
>>>
>>>
>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> To be clear : I’m annoyed with myself that this impacted a package that
>>>> depends on vector, but this does seem to be the case that the newest bug
>>>> fix release for vector actually revealed a broken design for the vector
>>>> instances / data types in the inline-r package.
>>>>
>>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>>> immutable vector data types
>>>>
>>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> so i took a look .. (also the inline-r devs seem to have done a
>>>>> hackage revision so you wont hit that issue in your current setup if you do
>>>>> a cabal update ..)
>>>>> and it seems like the type definitions in inline-r are kinda bogus
>>>>> and you should get them patched ...
>>>>>
>>>>> the MVector type class, and related type families, all assume your
>>>>> mutable type has the last two arguments as the io/state token and then the
>>>>> element type
>>>>>
>>>>> eg
>>>>> basicLength :: v s a -> Int
>>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>>>
>>>>>
>>>>> i looked at
>>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>>>> and
>>>>>
>>>>>
>>>>>
>>>>> as a point of grounding this chat
>>>>> the injective type familly in question is defined by the follwoing
>>>>>
>>>>>
>>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>>>
>>>>> anyways, it looks like the Pure / immutable vector data type in
>>>>> inline-r has a spurious state token argument in its definition that
>>>>> shouldn't be there, OR there need to be two "s" params in inline-r instead
>>>>> of the one
>>>>>
>>>>> heres the full code i linked to in question
>>>>>
>>>>>
>>>>> -- | Mutable R vector. Represented in memory with the same header as
>>>>> 'SEXP'
>>>>>
>>>>> -- nodes. The second type parameter is phantom, reflecting at the type
>>>>> level the
>>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
>>>>> and the
>>>>> -- representation type are related via 'ElemRep'.
>>>>> data MVector s ty a = MVector
>>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>>>> }
>>>>> -- | Internal wrapper type for reflection. First type parameter is the
>>>>> reified
>>>>> -- type to reflect.
>>>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
>>>>> ty) a where
>>>>>
>>>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
>>>>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>>>> }
>>>>>
>>>>>
>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>> Anyways, the fix here is to remove the s param from the Pure version
>>>>> of W and "Sexp Vector"
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> were you using the same version of vector in both setups?
>>>>>>
>>>>>> in the most recent  vector release  we made mutable type family
>>>>>> injective in the vector package for ghc's that support it ...
>>>>>>
>>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <djsamperi at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
>>>>>>> I get the error "Type family equation violates injectivity
>>>>>>> annotation," and
>>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>>>> the lack of injectivity (I suppose).
>>>>>>>
>>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under
>>>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>>>
>>>>>>> Has something changed in the latest version of the compiler that
>>>>>>> might
>>>>>>> cause this? Possible work-around?
>>>>>>>
>>>>>>> FYI, the line that triggers the error is:
>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>>
>>>>>>> The variable that cannot be inferred is 's'.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dominick
>>>>>>> _______________________________________________
>>>>>>> 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/20190104/22226732/attachment.html>

From carter.schonwald at gmail.com  Fri Jan  4 15:04:17 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 4 Jan 2019 10:04:17 -0500
Subject: Type family equation violates injectivity?
In-Reply-To: <CAO-1Pb4EH-CMdKO4J_exQUKh8rhyPiwi1+TqKSWB5eyxQ66wiQ@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
 <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
 <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>
 <CAO-1Pb4EH-CMdKO4J_exQUKh8rhyPiwi1+TqKSWB5eyxQ66wiQ@mail.gmail.com>
Message-ID: <CAHYVw0zifCb6d5kMH3_oO++r3-7NA5BCN8+7MoZ9PZ-zzaoUUA@mail.gmail.com>

Would it be easier if you can do a conjunction on vector and base version
in your cpp should you want to support both sides ?

On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
alexander.vershilov at gmail.com> wrote:

> For inline-r we have added a revision that sets upper limit, so now
> hackage and stackage should both be happy. I'm not sure if any Linux
> distribution provides inline-r as a package but that should be normal
> situation for them. Next version will either set lower dependency boundary
> or will keep a code that will run with both APIs. So from my perspective
> any solution (even keeping things as-is) will be ok.
>
>
> On Fri, Jan 4, 2019, 17:31 Carter Schonwald <carter.schonwald at gmail.com
> wrote:
>
>> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
>> bump and make the bug fix bump version unbuildable.
>>
>> Would this help matters ?
>>
>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Yeah, I later found it impacted one of my own pieces of code too, in
>>> that I needed to make still further type families injective.
>>>
>>> I do think that a lot of vectors current module structure reflects a
>>> desire for injectivity coupled with historical a lack of mechanism for
>>> guaranteeing it.
>>>
>>> Mess up on my part for sure.  :)
>>>
>>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:
>>>
>>>> Hi Carter,
>>>>
>>>> thanks for looking into this. We were initially surprised to see a
>>>> breaking change in a point release, but no biggy. It's pretty hard to offer
>>>> strong stability guarantees without automated tooling to catch this kind of
>>>> thing, and these things happen. We'll patch up HaskellR shortly.
>>>>
>>>> Best,
>>>>
>>>>
>>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> To be clear : I’m annoyed with myself that this impacted a package
>>>>> that depends on vector, but this does seem to be the case that the newest
>>>>> bug fix release for vector actually revealed a broken design for the vector
>>>>> instances / data types in the inline-r package.
>>>>>
>>>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>>>> immutable vector data types
>>>>>
>>>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> so i took a look .. (also the inline-r devs seem to have done a
>>>>>> hackage revision so you wont hit that issue in your current setup if you do
>>>>>> a cabal update ..)
>>>>>> and it seems like the type definitions in inline-r are kinda bogus
>>>>>> and you should get them patched ...
>>>>>>
>>>>>> the MVector type class, and related type families, all assume your
>>>>>> mutable type has the last two arguments as the io/state token and then the
>>>>>> element type
>>>>>>
>>>>>> eg
>>>>>> basicLength :: v s a -> Int
>>>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>>>>
>>>>>>
>>>>>> i looked at
>>>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>>>>> and
>>>>>>
>>>>>>
>>>>>>
>>>>>> as a point of grounding this chat
>>>>>> the injective type familly in question is defined by the follwoing
>>>>>>
>>>>>>
>>>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>>>>
>>>>>> anyways, it looks like the Pure / immutable vector data type in
>>>>>> inline-r has a spurious state token argument in its definition that
>>>>>> shouldn't be there, OR there need to be two "s" params in inline-r instead
>>>>>> of the one
>>>>>>
>>>>>> heres the full code i linked to in question
>>>>>>
>>>>>>
>>>>>> -- | Mutable R vector. Represented in memory with the same header as
>>>>>> 'SEXP'
>>>>>>
>>>>>> -- nodes. The second type parameter is phantom, reflecting at the
>>>>>> type level the
>>>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
>>>>>> and the
>>>>>> -- representation type are related via 'ElemRep'.
>>>>>> data MVector s ty a = MVector
>>>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>>>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>>>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>>>>> }
>>>>>> -- | Internal wrapper type for reflection. First type parameter is
>>>>>> the reified
>>>>>> -- type to reflect.
>>>>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
>>>>>> ty) a where
>>>>>>
>>>>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset
>>>>>> :: {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>>>>> }
>>>>>>
>>>>>>
>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>> Anyways, the fix here is to remove the s param from the Pure version
>>>>>> of W and "Sexp Vector"
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> were you using the same version of vector in both setups?
>>>>>>>
>>>>>>> in the most recent  vector release  we made mutable type family
>>>>>>> injective in the vector package for ghc's that support it ...
>>>>>>>
>>>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <
>>>>>>> djsamperi at gmail.com> wrote:
>>>>>>>
>>>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r
>>>>>>>> package
>>>>>>>> I get the error "Type family equation violates injectivity
>>>>>>>> annotation," and
>>>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>>>>> the lack of injectivity (I suppose).
>>>>>>>>
>>>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform
>>>>>>>> under
>>>>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>>>>
>>>>>>>> Has something changed in the latest version of the compiler that
>>>>>>>> might
>>>>>>>> cause this? Possible work-around?
>>>>>>>>
>>>>>>>> FYI, the line that triggers the error is:
>>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>>>
>>>>>>>> The variable that cannot be inferred is 's'.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dominick
>>>>>>>> _______________________________________________
>>>>>>>> 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/20190104/19fe223d/attachment.html>

From alexander.vershilov at gmail.com  Fri Jan  4 15:09:27 2019
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Fri, 4 Jan 2019 18:09:27 +0300
Subject: Type family equation violates injectivity?
In-Reply-To: <CAHYVw0zifCb6d5kMH3_oO++r3-7NA5BCN8+7MoZ9PZ-zzaoUUA@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
 <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
 <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>
 <CAO-1Pb4EH-CMdKO4J_exQUKh8rhyPiwi1+TqKSWB5eyxQ66wiQ@mail.gmail.com>
 <CAHYVw0zifCb6d5kMH3_oO++r3-7NA5BCN8+7MoZ9PZ-zzaoUUA@mail.gmail.com>
Message-ID: <CAO-1Pb7R8wOz6FNmj1HeeA-+Vqw5ifbS9q4RNPfE5CTiqXjs-g@mail.gmail.com>

I can't answer your question before I will port inline-r to the newer
vector. I would prefer to support both version and keep CPP around, like
you suggested, but the answer depends on the amount of changes I need to
keep. If that would be few lines of code then I'll go with that, in the
side if the amount of changes will be comparable with a module size, then
I'd prefer to cut out older versions.

On Fri, Jan 4, 2019, 18:04 Carter Schonwald <carter.schonwald at gmail.com
wrote:

> Would it be easier if you can do a conjunction on vector and base version
> in your cpp should you want to support both sides ?
>
> On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
> alexander.vershilov at gmail.com> wrote:
>
>> For inline-r we have added a revision that sets upper limit, so now
>> hackage and stackage should both be happy. I'm not sure if any Linux
>> distribution provides inline-r as a package but that should be normal
>> situation for them. Next version will either set lower dependency boundary
>> or will keep a code that will run with both APIs. So from my perspective
>> any solution (even keeping things as-is) will be ok.
>>
>>
>> On Fri, Jan 4, 2019, 17:31 Carter Schonwald <carter.schonwald at gmail.com
>> wrote:
>>
>>> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
>>> bump and make the bug fix bump version unbuildable.
>>>
>>> Would this help matters ?
>>>
>>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Yeah, I later found it impacted one of my own pieces of code too, in
>>>> that I needed to make still further type families injective.
>>>>
>>>> I do think that a lot of vectors current module structure reflects a
>>>> desire for injectivity coupled with historical a lack of mechanism for
>>>> guaranteeing it.
>>>>
>>>> Mess up on my part for sure.  :)
>>>>
>>>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:
>>>>
>>>>> Hi Carter,
>>>>>
>>>>> thanks for looking into this. We were initially surprised to see a
>>>>> breaking change in a point release, but no biggy. It's pretty hard to offer
>>>>> strong stability guarantees without automated tooling to catch this kind of
>>>>> thing, and these things happen. We'll patch up HaskellR shortly.
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> To be clear : I’m annoyed with myself that this impacted a package
>>>>>> that depends on vector, but this does seem to be the case that the newest
>>>>>> bug fix release for vector actually revealed a broken design for the vector
>>>>>> instances / data types in the inline-r package.
>>>>>>
>>>>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>>>>> immutable vector data types
>>>>>>
>>>>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> so i took a look .. (also the inline-r devs seem to have done a
>>>>>>> hackage revision so you wont hit that issue in your current setup if you do
>>>>>>> a cabal update ..)
>>>>>>> and it seems like the type definitions in inline-r are kinda bogus
>>>>>>> and you should get them patched ...
>>>>>>>
>>>>>>> the MVector type class, and related type families, all assume your
>>>>>>> mutable type has the last two arguments as the io/state token and then the
>>>>>>> element type
>>>>>>>
>>>>>>> eg
>>>>>>> basicLength :: v s a -> Int
>>>>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>>>>>
>>>>>>>
>>>>>>> i looked at
>>>>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>>>>>> and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> as a point of grounding this chat
>>>>>>> the injective type familly in question is defined by the follwoing
>>>>>>>
>>>>>>>
>>>>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>>>>>
>>>>>>> anyways, it looks like the Pure / immutable vector data type in
>>>>>>> inline-r has a spurious state token argument in its definition that
>>>>>>> shouldn't be there, OR there need to be two "s" params in inline-r instead
>>>>>>> of the one
>>>>>>>
>>>>>>> heres the full code i linked to in question
>>>>>>>
>>>>>>>
>>>>>>> -- | Mutable R vector. Represented in memory with the same header
>>>>>>> as 'SEXP'
>>>>>>>
>>>>>>> -- nodes. The second type parameter is phantom, reflecting at the
>>>>>>> type level the
>>>>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
>>>>>>> and the
>>>>>>> -- representation type are related via 'ElemRep'.
>>>>>>> data MVector s ty a = MVector
>>>>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>>>>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>>>>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>>>>>> }
>>>>>>> -- | Internal wrapper type for reflection. First type parameter is
>>>>>>> the reified
>>>>>>> -- type to reflect.
>>>>>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>>>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
>>>>>>> ty) a where
>>>>>>>
>>>>>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>>>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset
>>>>>>> :: {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>> Anyways, the fix here is to remove the s param from the Pure version
>>>>>>> of W and "Sexp Vector"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> were you using the same version of vector in both setups?
>>>>>>>>
>>>>>>>> in the most recent  vector release  we made mutable type family
>>>>>>>> injective in the vector package for ghc's that support it ...
>>>>>>>>
>>>>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <
>>>>>>>> djsamperi at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r
>>>>>>>>> package
>>>>>>>>> I get the error "Type family equation violates injectivity
>>>>>>>>> annotation," and
>>>>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>>>>>> the lack of injectivity (I suppose).
>>>>>>>>>
>>>>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform
>>>>>>>>> under
>>>>>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>>>>>
>>>>>>>>> Has something changed in the latest version of the compiler that
>>>>>>>>> might
>>>>>>>>> cause this? Possible work-around?
>>>>>>>>>
>>>>>>>>> FYI, the line that triggers the error is:
>>>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>>>>
>>>>>>>>> The variable that cannot be inferred is 's'.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dominick
>>>>>>>>> _______________________________________________
>>>>>>>>> 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/20190104/7afbb13e/attachment-0001.html>

From matthewtpickering at gmail.com  Fri Jan  4 15:21:40 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 4 Jan 2019 15:21:40 +0000
Subject: Default options for -threaded
In-Reply-To: <CANsrgPJnh5wZDfq=n_N76-f5CHKLC=Vnwg1=qDGg1sFi3Jx1OQ@mail.gmail.com>
References: <57f92249.4d081c0a.292b6.e00a@mx.google.com>
 <87mvielr0q.fsf@ben-laptop.smart-cactus.org>
 <CANsrgPJnh5wZDfq=n_N76-f5CHKLC=Vnwg1=qDGg1sFi3Jx1OQ@mail.gmail.com>
Message-ID: <CALuQ0m8AHg=1M0ai0t6oEvOR9eDAQmef4cUvFbrsbwG1NAt7xQ@mail.gmail.com>

Two years seems a good amount of time for any objectors.

https://ghc.haskell.org/trac/ghc/ticket/16126#ticket

On Fri, Oct 21, 2016 at 5:35 PM Simon Marlow <marlowsd at gmail.com> wrote:
>
> On 8 October 2016 at 17:55, Ben Gamari <ben at well-typed.com> wrote:
>>
>> lonetiger at gmail.com writes:
>>
>> > Hi All,
>> >
>> > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why
>> > -N -qa isn’t the default for -threaded.
>> >
>> I'm not sure that scheduling on all of the cores on the user's machine by
>> default is a good idea, especially given that our users have
>> learned to expect the existing default. Enabling affinity by default
>> seems reasonable if we have evidence that it helps the majority of
>> applications, but we would first need to introduce an additional
>> flag to disable it.
>
>
> Affinity is almost always a bad idea in my experience.
>
>>
>> In general I think -N1 is a reasonable default as it acknowledges the
>> fact that deploying parallelism is not something that can be done
>> blindly in many (most?) applications. To make effective use of
>> parallelism the user needs to understand their hardware, their
>> application, and its interaction with the runtime system and configure
>> the RTS appropriately.
>>
>
> Agree on keeping -N1.
>
> Related to this, I think it's about time we made -threaded the default.  We could add a -single-threaded option to get back the old behaviour.
>
> There is a small overhead to using -threaded, but -threaded is also required to make a lot of things work (e.g. waitForProcess in a multithreaded program, not to mention parallelism).
>
> Anyone interested in doing this?
>
> Cheers
> Simon
>
>
>>
>> Of course, this is just my two-cents.
>>
>> 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

From carter.schonwald at gmail.com  Fri Jan  4 15:30:04 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 4 Jan 2019 10:30:04 -0500
Subject: Type family equation violates injectivity?
In-Reply-To: <CAO-1Pb7R8wOz6FNmj1HeeA-+Vqw5ifbS9q4RNPfE5CTiqXjs-g@mail.gmail.com>
References: <CADUbQ5iOB-O5KMWN482Ercjfh9Wn2=ZE3TjPxetJyHKqt3tyRw@mail.gmail.com>
 <CAHYVw0zbX5AxNxqLXnedfw4OEraeSK3PK_Vz500ugocKqxZ5Qw@mail.gmail.com>
 <CAHYVw0wAm7W-8OG55zW3tMMF3Anm4uEw=Z4=41=KpOcdP1QBqg@mail.gmail.com>
 <CAHYVw0zaiW5a7yzndwghbvfWhr5f6A-NTrAwT+ANZuK8MxzxnA@mail.gmail.com>
 <CAJ0eudqo-voVXnh9CRHfAUeDF_6vs+YUAFW0DX96VxCc0-O25A@mail.gmail.com>
 <CAHYVw0yp0jfn4W88o+1xOafJuwNyUATchz9PbiHCx=X+WCQvwA@mail.gmail.com>
 <CAHYVw0wXpt21vv0r34+QHakx3sqzCy_gy4hs=KQs2G_e3eVuqA@mail.gmail.com>
 <CAO-1Pb4EH-CMdKO4J_exQUKh8rhyPiwi1+TqKSWB5eyxQ66wiQ@mail.gmail.com>
 <CAHYVw0zifCb6d5kMH3_oO++r3-7NA5BCN8+7MoZ9PZ-zzaoUUA@mail.gmail.com>
 <CAO-1Pb7R8wOz6FNmj1HeeA-+Vqw5ifbS9q4RNPfE5CTiqXjs-g@mail.gmail.com>
Message-ID: <CAHYVw0yQoPxP9wdSbuQ_ZXL6ULOgXdiwxWL9LQOC677VTktqjw@mail.gmail.com>

Ok, either way it might be nice to just make it a minor bump.  I’ll see
what I can do :)

On Fri, Jan 4, 2019 at 10:09 AM Alexander V Vershilov <
alexander.vershilov at gmail.com> wrote:

> I can't answer your question before I will port inline-r to the newer
> vector. I would prefer to support both version and keep CPP around, like
> you suggested, but the answer depends on the amount of changes I need to
> keep. If that would be few lines of code then I'll go with that, in the
> side if the amount of changes will be comparable with a module size, then
> I'd prefer to cut out older versions.
>
> On Fri, Jan 4, 2019, 18:04 Carter Schonwald <carter.schonwald at gmail.com
> wrote:
>
>> Would it be easier if you can do a conjunction on vector and base version
>> in your cpp should you want to support both sides ?
>>
>> On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
>> alexander.vershilov at gmail.com> wrote:
>>
>>> For inline-r we have added a revision that sets upper limit, so now
>>> hackage and stackage should both be happy. I'm not sure if any Linux
>>> distribution provides inline-r as a package but that should be normal
>>> situation for them. Next version will either set lower dependency boundary
>>> or will keep a code that will run with both APIs. So from my perspective
>>> any solution (even keeping things as-is) will be ok.
>>>
>>>
>>> On Fri, Jan 4, 2019, 17:31 Carter Schonwald <carter.schonwald at gmail.com
>>> wrote:
>>>
>>>> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
>>>> bump and make the bug fix bump version unbuildable.
>>>>
>>>> Would this help matters ?
>>>>
>>>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> Yeah, I later found it impacted one of my own pieces of code too, in
>>>>> that I needed to make still further type families injective.
>>>>>
>>>>> I do think that a lot of vectors current module structure reflects a
>>>>> desire for injectivity coupled with historical a lack of mechanism for
>>>>> guaranteeing it.
>>>>>
>>>>> Mess up on my part for sure.  :)
>>>>>
>>>>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m at tweag.io> wrote:
>>>>>
>>>>>> Hi Carter,
>>>>>>
>>>>>> thanks for looking into this. We were initially surprised to see a
>>>>>> breaking change in a point release, but no biggy. It's pretty hard to offer
>>>>>> strong stability guarantees without automated tooling to catch this kind of
>>>>>> thing, and these things happen. We'll patch up HaskellR shortly.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>
>>>>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> To be clear : I’m annoyed with myself that this impacted a package
>>>>>>> that depends on vector, but this does seem to be the case that the newest
>>>>>>> bug fix release for vector actually revealed a broken design for the vector
>>>>>>> instances / data types in the inline-r package.
>>>>>>>
>>>>>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>>>>>> immutable vector data types
>>>>>>>
>>>>>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>> so i took a look .. (also the inline-r devs seem to have done a
>>>>>>>> hackage revision so you wont hit that issue in your current setup if you do
>>>>>>>> a cabal update ..)
>>>>>>>> and it seems like the type definitions in inline-r are kinda bogus
>>>>>>>> and you should get them patched ...
>>>>>>>>
>>>>>>>> the MVector type class, and related type families, all assume your
>>>>>>>> mutable type has the last two arguments as the io/state token and then the
>>>>>>>> element type
>>>>>>>>
>>>>>>>> eg
>>>>>>>> basicLength :: v s a -> Int
>>>>>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int>
>>>>>>>>
>>>>>>>>
>>>>>>>> i looked at
>>>>>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>>>>>>> and
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> as a point of grounding this chat
>>>>>>>> the injective type familly in question is defined by the follwoing
>>>>>>>>
>>>>>>>>
>>>>>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> (v <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> :: * -> *) = (mv <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * -> *#endif
>>>>>>>>
>>>>>>>> anyways, it looks like the Pure / immutable vector data type in
>>>>>>>> inline-r has a spurious state token argument in its definition that
>>>>>>>> shouldn't be there, OR there need to be two "s" params in inline-r instead
>>>>>>>> of the one
>>>>>>>>
>>>>>>>> heres the full code i linked to in question
>>>>>>>>
>>>>>>>>
>>>>>>>> -- | Mutable R vector. Represented in memory with the same header
>>>>>>>> as 'SEXP'
>>>>>>>>
>>>>>>>> -- nodes. The second type parameter is phantom, reflecting at the
>>>>>>>> type level the
>>>>>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
>>>>>>>> and the
>>>>>>>> -- representation type are related via 'ElemRep'.
>>>>>>>> data MVector s ty a = MVector
>>>>>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>>>>>>>> , mvectorOffset :: {-# UNPACK #-} !Int32
>>>>>>>> , mvectorLength :: {-# UNPACK #-} !Int32
>>>>>>>> }
>>>>>>>> -- | Internal wrapper type for reflection. First type parameter is
>>>>>>>> the reified
>>>>>>>> -- type to reflect.
>>>>>>>> newtype W t ty s a = W { unW :: MVector s ty a }
>>>>>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
>>>>>>>> ty) a where
>>>>>>>>
>>>>>>>> data Vector s (ty :: SEXPTYPE) a = Vector
>>>>>>>>     { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset
>>>>>>>> :: {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>>> Anyways, the fix here is to remove the s param from the Pure
>>>>>>>> version of W and "Sexp Vector"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> were you using the same version of vector in both setups?
>>>>>>>>>
>>>>>>>>> in the most recent  vector release  we made mutable type family
>>>>>>>>> injective in the vector package for ghc's that support it ...
>>>>>>>>>
>>>>>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi <
>>>>>>>>> djsamperi at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r
>>>>>>>>>> package
>>>>>>>>>> I get the error "Type family equation violates injectivity
>>>>>>>>>> annotation," and
>>>>>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to
>>>>>>>>>> the lack of injectivity (I suppose).
>>>>>>>>>>
>>>>>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform
>>>>>>>>>> under
>>>>>>>>>> Ubuntu) does not have this problem (it has other problems).
>>>>>>>>>>
>>>>>>>>>> Has something changed in the latest version of the compiler that
>>>>>>>>>> might
>>>>>>>>>> cause this? Possible work-around?
>>>>>>>>>>
>>>>>>>>>> FYI, the line that triggers the error is:
>>>>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>>>>>>>>>>
>>>>>>>>>> The variable that cannot be inferred is 's'.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dominick
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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/20190104/740f1842/attachment.html>

From carter.schonwald at gmail.com  Fri Jan  4 15:31:09 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 4 Jan 2019 10:31:09 -0500
Subject: Default options for -threaded
In-Reply-To: <CALuQ0m8AHg=1M0ai0t6oEvOR9eDAQmef4cUvFbrsbwG1NAt7xQ@mail.gmail.com>
References: <57f92249.4d081c0a.292b6.e00a@mx.google.com>
 <87mvielr0q.fsf@ben-laptop.smart-cactus.org>
 <CANsrgPJnh5wZDfq=n_N76-f5CHKLC=Vnwg1=qDGg1sFi3Jx1OQ@mail.gmail.com>
 <CALuQ0m8AHg=1M0ai0t6oEvOR9eDAQmef4cUvFbrsbwG1NAt7xQ@mail.gmail.com>
Message-ID: <CAHYVw0wZ-C_vY8n4ijFnWT1TcmOCP3Y-Kn-MCHo_Z9AyXHCp+Q@mail.gmail.com>

Yup! Let’s do it. Efficient io and compute during ffi computation sound
good to me

On Fri, Jan 4, 2019 at 10:22 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Two years seems a good amount of time for any objectors.
>
> https://ghc.haskell.org/trac/ghc/ticket/16126#ticket
>
> On Fri, Oct 21, 2016 at 5:35 PM Simon Marlow <marlowsd at gmail.com> wrote:
> >
> > On 8 October 2016 at 17:55, Ben Gamari <ben at well-typed.com> wrote:
> >>
> >> lonetiger at gmail.com writes:
> >>
> >> > Hi All,
> >> >
> >> > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why
> >> > -N -qa isn’t the default for -threaded.
> >> >
> >> I'm not sure that scheduling on all of the cores on the user's machine
> by
> >> default is a good idea, especially given that our users have
> >> learned to expect the existing default. Enabling affinity by default
> >> seems reasonable if we have evidence that it helps the majority of
> >> applications, but we would first need to introduce an additional
> >> flag to disable it.
> >
> >
> > Affinity is almost always a bad idea in my experience.
> >
> >>
> >> In general I think -N1 is a reasonable default as it acknowledges the
> >> fact that deploying parallelism is not something that can be done
> >> blindly in many (most?) applications. To make effective use of
> >> parallelism the user needs to understand their hardware, their
> >> application, and its interaction with the runtime system and configure
> >> the RTS appropriately.
> >>
> >
> > Agree on keeping -N1.
> >
> > Related to this, I think it's about time we made -threaded the default.
> We could add a -single-threaded option to get back the old behaviour.
> >
> > There is a small overhead to using -threaded, but -threaded is also
> required to make a lot of things work (e.g. waitForProcess in a
> multithreaded program, not to mention parallelism).
> >
> > Anyone interested in doing this?
> >
> > Cheers
> > Simon
> >
> >
> >>
> >> Of course, this is just my two-cents.
> >>
> >> 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
> _______________________________________________
> 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/20190104/aff1e40a/attachment.html>

From v.dijk.bas at gmail.com  Fri Jan  4 15:50:02 2019
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Fri, 4 Jan 2019 16:50:02 +0100
Subject: Failure to catch C++ exception in Haskell on OS X
In-Reply-To: <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>
References: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
 <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>
Message-ID: <CADLz5wWKkC4yJ=ytOPiuaKh3WYmvw34_bQ-dg5d_0QqyewGnGA@mail.gmail.com>

On Fri, 4 Jan 2019 at 14:15, Gabor Greif <ggreif at gmail.com> wrote:
> maybe some DWARF unwind tables are not correctly installed in OS X?

Hi Gabor, thanks, I will look into that.

> Do intra-C++ exception catching work in your example?

Yes, I have a C++ executable foo[1] that links with libfoo that
correctly catches the exception:

  > $(nix-build --no-link -A foo)/bin/test
  ...
  Whoops!

Since it's working in pure C++ I suspect it has something to do with
how GHC calls either the C++ compiler or linker.

Bas

[1] https://github.com/basvandijk/darwin-cxx-exception-bug/blob/master/foo/test.cpp

From simonpj at microsoft.com  Fri Jan  4 16:19:27 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Jan 2019 16:19:27 +0000
Subject: Gitlab pain
Message-ID: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I'm getting lost in a maze of twisty little passages, all alike.
I'm looking at
https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877
and
https://gitlab.haskell.org/ghc/ghc/merge_requests/10

But the note in the former starting "Another module should reference the symbol..." doesn't show up in the latter, anywhere.
How can I see the current state of play on this MR, the ground truth?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190104/4ab0bfb7/attachment.html>

From rae at cs.brynmawr.edu  Fri Jan  4 16:25:36 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 4 Jan 2019 11:25:36 -0500
Subject: Gitlab pain
In-Reply-To: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>

GitLab groups posts on lines in MRs as "discussions". A discussion can be *resolved*. When it is resolved, the discussion is collapsed by default when you view the MR. The particular comment you're seeking can be found on the MR if you open the discussion you started at 10:04am this morning (GMT) and that Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers like in Trac.)

I'm still learning my way around, too, so correct me (anyone) if there's a better way to describe all this.

Richard

> On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> I’m getting lost in a maze of twisty little passages, all alike.
> 
> I’m looking at
> 
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877 <https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877>
> and
> 
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10 <https://gitlab.haskell.org/ghc/ghc/merge_requests/10>
>  
> 
> But the note in the former starting “Another module should reference the symbol…” doesn’t show up in the latter, anywhere. 
> 
> How can I see the current state of play on this MR, the ground truth?
> 
> 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 <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/20190104/91b39942/attachment.html>

From rae at cs.brynmawr.edu  Fri Jan  4 16:42:23 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 4 Jan 2019 11:42:23 -0500
Subject: GitLab: Cmd+Enter considered harmful on reviews
Message-ID: <6FC47138-6BE0-4DA9-A1C8-A5590398B116@cs.brynmawr.edu>

PSA: When reviewing an MR on GitLab, every comment has two buttons: (1) add to review, and (2) add comment now. Cmd+Enter (on my machine at least), does option (2), even though option (1) is bold and green. This is not what I wanted. (By the way, "comments" actually open these things called "discussions", which can be resolved. But that's another matter.)

I've now removed all my comments and added them to my review. But I wanted you all to know about this in case you stumble across the same problem.

Richard

From simonpj at microsoft.com  Fri Jan  4 17:12:44 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Jan 2019 17:12:44 +0000
Subject: Gitlab pain
In-Reply-To: <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308532D4420253A8D1A20BDAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Thanks.  But I cannot work out

  *   How to find this “collapsed” discussion
  *   How to un-collapse it
  *   How to search for stuff in collapsed discussions. (Finding them one at a time, uncollapsing, and searching, seems wrong.)  How can I un-collapse everything?
Simon


From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 04 January 2019 16:26
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Gitlab pain

GitLab groups posts on lines in MRs as "discussions". A discussion can be *resolved*. When it is resolved, the discussion is collapsed by default when you view the MR. The particular comment you're seeking can be found on the MR if you open the discussion you started at 10:04am this morning (GMT) and that Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers like in Trac.)

I'm still learning my way around, too, so correct me (anyone) if there's a better way to describe all this.

Richard


On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:

I’m getting lost in a maze of twisty little passages, all alike.
I’m looking at
https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10%23note_1877&data=02%7C01%7Csimonpj%40microsoft.com%7Cf600b9368d7744df6b6208d6726143c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822159410898564&sdata=JQDAfsWoH15VkXpIbyHsUR5vnss3I1STNJsYevAMUsk%3D&reserved=0>
and
https://gitlab.haskell.org/ghc/ghc/merge_requests/10<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10&data=02%7C01%7Csimonpj%40microsoft.com%7Cf600b9368d7744df6b6208d6726143c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822159410898564&sdata=1e%2Bu6zu8v4Op0RhKu%2Fxi3W3eqQLNgGV9v4evOjuhnVk%3D&reserved=0>

But the note in the former starting “Another module should reference the symbol…” doesn’t show up in the latter, anywhere.
How can I see the current state of play on this MR, the ground truth?
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%7Cf600b9368d7744df6b6208d6726143c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822159410908569&sdata=DPO3PEtO2wDhcuS8BEhuk6IgvEU0Ym2pSFUy0fmYb3s%3D&reserved=0>

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

From qdunkan at gmail.com  Fri Jan  4 17:13:23 2019
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 5 Jan 2019 01:13:23 +0800
Subject: Gitlab pain
In-Reply-To: <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
Message-ID: <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>

The diff in https://gitlab.haskell.org/ghc/ghc/merge_requests/10/diffs
is the ground truth for the source code.  However, it's not ground
truth for comments.  You only get to see the ones attached to the
revisions selected in "Changes between x and y", which means they tend
to get lost.  The Discussion tab is ground truth for comments in that
you won't miss any if you look through it, but it gets cluttered.
There should be a "skip to first unresolved comment" button, which
helps.  I wish it let you cycle them instead of always going to the
first.  But the discussion tab is not good for seeing what the change
being discussed actually is, so you have to go back to Changes, at
which point you lose your place in Discussion.

If anyone knows a better way to do comments I'd also like to know... I
use gitlab at work and find it pretty awkward for medium-and-up sized
reviews.

On Sat, Jan 5, 2019 at 12:25 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
> GitLab groups posts on lines in MRs as "discussions". A discussion can be *resolved*. When it is resolved, the discussion is collapsed by default when you view the MR. The particular comment you're seeking can be found on the MR if you open the discussion you started at 10:04am this morning (GMT) and that Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers like in Trac.)
>
> I'm still learning my way around, too, so correct me (anyone) if there's a better way to describe all this.
>
> Richard
>
> On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
>
> I’m getting lost in a maze of twisty little passages, all alike.
>
> I’m looking at
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877
>
> and
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10
>
>
>
> But the note in the former starting “Another module should reference the symbol…” doesn’t show up in the latter, anywhere.
>
> How can I see the current state of play on this MR, the ground truth?
>
> 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  Fri Jan  4 17:20:48 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Jan 2019 17:20:48 +0000
Subject: Gitlab pain
In-Reply-To: <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
Message-ID: <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  The Discussion tab is ground truth for comments in that you won't miss any
|  if you look through it, but it gets cluttered.

Apparently not.  Check out
https://gitlab.haskell.org/ghc/ghc/merge_requests/10
and search for "Another module should reference the symbol" which is definitely in a comment.

Maybe I'm missing something.

Simon

|  -----Original Message-----
|  From: Evan Laforge <qdunkan at gmail.com>
|  Sent: 04 January 2019 17:13
|  To: Richard Eisenberg <rae at cs.brynmawr.edu>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: Gitlab pain
|  
|  The diff in
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
|  skell.org%2Fghc%2Fghc%2Fmerge_requests%2F10%2Fdiffs&amp;data=02%7C01%7Csimo
|  npj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988bf86f141af91
|  ab2d7cd011db47%7C1%7C0%7C636822188176178183&amp;sdata=wJWw5HxSWePGKWWZYEPbr
|  dWrhADmIWHalekobnEgiTo%3D&amp;reserved=0
|  is the ground truth for the source code.  However, it's not ground truth
|  for comments.  You only get to see the ones attached to the revisions
|  selected in "Changes between x and y", which means they tend to get lost.
|  The Discussion tab is ground truth for comments in that you won't miss any
|  if you look through it, but it gets cluttered.
|  There should be a "skip to first unresolved comment" button, which helps.
|  I wish it let you cycle them instead of always going to the first.  But the
|  discussion tab is not good for seeing what the change being discussed
|  actually is, so you have to go back to Changes, at which point you lose
|  your place in Discussion.
|  
|  If anyone knows a better way to do comments I'd also like to know... I use
|  gitlab at work and find it pretty awkward for medium-and-up sized reviews.
|  
|  On Sat, Jan 5, 2019 at 12:25 AM Richard Eisenberg <rae at cs.brynmawr.edu>
|  wrote:
|  >
|  > GitLab groups posts on lines in MRs as "discussions". A discussion can
|  > be *resolved*. When it is resolved, the discussion is collapsed by
|  > default when you view the MR. The particular comment you're seeking
|  > can be found on the MR if you open the discussion you started at
|  > 10:04am this morning (GMT) and that Gabor closed at 2:10pm this
|  > afternoon. (I'm already missing comment numbers like in Trac.)
|  >
|  > I'm still learning my way around, too, so correct me (anyone) if there's
|  a better way to describe all this.
|  >
|  > Richard
|  >
|  > On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org> wrote:
|  >
|  > I’m getting lost in a maze of twisty little passages, all alike.
|  >
|  > I’m looking at
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10%23note_1877&amp;data=
|  > 02%7C01%7Csimonpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7
|  > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176178183&amp;sda
|  > ta=ht6hBYw5rfjSMmpYsmwNnyhxEvHIdjyy%2FLqA2FB1dC8%3D&amp;reserved=0
|  >
|  > and
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10&amp;data=02%7C01%7Csi
|  > monpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988bf86f
|  > 141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191&amp;sdata=1N2eoL7dC
|  > 8ElWQ6zyAW4wXBQcaRv4bCk%2FnrrKS%2BlLfI%3D&amp;reserved=0
|  >
|  >
|  >
|  > But the note in the former starting “Another module should reference the
|  symbol…” doesn’t show up in the latter, anywhere.
|  >
|  > How can I see the current state of play on this MR, the ground truth?
|  >
|  > Simon
|  >
|  > _______________________________________________
|  > 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%7C13d19e5c0e4c4398715a08d67267f643%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191&amp;sdata=PJj9
|  > 2UnmQNNeCFVTt1d8XWSVCcuSAalMJsq152DEfqA%3D&amp;reserved=0
|  >
|  >
|  > _______________________________________________
|  > 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%7C13d19e5c0e4c4398715a08d67267f643%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191&amp;sdata=PJj9
|  > 2UnmQNNeCFVTt1d8XWSVCcuSAalMJsq152DEfqA%3D&amp;reserved=0

From me at ara.io  Fri Jan  4 17:56:58 2019
From: me at ara.io (Ara Adkins)
Date: Fri, 4 Jan 2019 17:56:58 +0000
Subject: The GHC Proposals Process
Message-ID: <CACPahm3oMRR3DXXCM5nSpDAWEjDJBLQ03ow3yNfiuEq-UJB9CQ@mail.gmail.com>

Hey All,

Now we have our own git instance in GitLab, are there any plans to move the
proposals process from GitHub?

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

From ben at smart-cactus.org  Fri Jan  4 18:01:47 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 04 Jan 2019 13:01:47 -0500
Subject: Gitlab pain
In-Reply-To: <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87tvionvy2.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> |  The Discussion tab is ground truth for comments in that you won't miss any
> |  if you look through it, but it gets cluttered.
>
> Apparently not.  Check out
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10
> and search for "Another module should reference the symbol" which is definitely in a comment.
>
> Maybe I'm missing something.
>
My apologies for the slow reply. I've been a bit under the weather this
week; there has been a lot of time spent on the couch.

As mentioned by others, discussions that have been marked as "resolved"
are collapsed by default. If you search for the text "Toggle discussion"
you will find that the collapsed discussions have link on their
right-hand side which you can click on to expand the hidden comments.

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/20190104/91188404/attachment.sig>

From allbery.b at gmail.com  Fri Jan  4 18:04:43 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 4 Jan 2019 13:04:43 -0500
Subject: Gitlab pain
In-Reply-To: <87tvionvy2.fsf@smart-cactus.org>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87tvionvy2.fsf@smart-cactus.org>
Message-ID: <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>

On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari <ben at smart-cactus.org> wrote:

> As mentioned by others, discussions that have been marked as "resolved"
> are collapsed by default. If you search for the text "Toggle discussion"
> you will find that the collapsed discussions have link on their
> right-hand side which you can click on to expand the hidden comments.
>

The problem there being there's a lot of such, and no way to tell which one
is relevant unless you have both original links and enough context. Finding
stuff like that absent context doesn't look at all easy. :/

-- 
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/20190104/874c73f6/attachment.html>

From ben at smart-cactus.org  Fri Jan  4 18:09:05 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 04 Jan 2019 13:09:05 -0500
Subject: GitLab: Cmd+Enter considered harmful on reviews
In-Reply-To: <6FC47138-6BE0-4DA9-A1C8-A5590398B116@cs.brynmawr.edu>
References: <6FC47138-6BE0-4DA9-A1C8-A5590398B116@cs.brynmawr.edu>
Message-ID: <87r2dsnvls.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> PSA: When reviewing an MR on GitLab, every comment has two buttons:
> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine
> at least), does option (2), even though option (1) is bold and green.
> This is not what I wanted. (By the way, "comments" actually open these
> things called "discussions", which can be resolved. But that's another
> matter.)
>
Hmm, strange. I can't seem to reproduce this. Which browser are you
using?

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/20190104/3555cece/attachment.sig>

From rae at cs.brynmawr.edu  Fri Jan  4 18:12:37 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 4 Jan 2019 13:12:37 -0500
Subject: GitLab: Cmd+Enter considered harmful on reviews
In-Reply-To: <87r2dsnvls.fsf@smart-cactus.org>
References: <6FC47138-6BE0-4DA9-A1C8-A5590398B116@cs.brynmawr.edu>
 <87r2dsnvls.fsf@smart-cactus.org>
Message-ID: <795D323E-04C0-4166-B395-84C09D700C83@cs.brynmawr.edu>

I'm on Firefox.

It doesn't matter all that much, really. I was hoping that a review was its own thing. But GitLab doesn't do that: a review is just a set of comments all delivered at the same time. Now that I've posted my review, my comments have become 49 separate "discussions". Oof.

Richard

> On Jan 4, 2019, at 1:09 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> 
>> PSA: When reviewing an MR on GitLab, every comment has two buttons:
>> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine
>> at least), does option (2), even though option (1) is bold and green.
>> This is not what I wanted. (By the way, "comments" actually open these
>> things called "discussions", which can be resolved. But that's another
>> matter.)
>> 
> Hmm, strange. I can't seem to reproduce this. Which browser are you
> using?
> 
> Cheers,
> 
> - Ben
> 


From ben at well-typed.com  Fri Jan  4 18:47:48 2019
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 04 Jan 2019 13:47:48 -0500
Subject: Gitlab pain
In-Reply-To: <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87tvionvy2.fsf@smart-cactus.org>
 <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>
Message-ID: <B637EC3A-702F-435F-AB07-B38804E8AB06@well-typed.com>

Quite right. I will bring this up with upstream. 

On January 4, 2019 1:04:43 PM EST, Brandon Allbery <allbery.b at gmail.com> wrote:
>On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari <ben at smart-cactus.org> wrote:
>
>> As mentioned by others, discussions that have been marked as
>"resolved"
>> are collapsed by default. If you search for the text "Toggle
>discussion"
>> you will find that the collapsed discussions have link on their
>> right-hand side which you can click on to expand the hidden comments.
>>
>
>The problem there being there's a lot of such, and no way to tell which
>one
>is relevant unless you have both original links and enough context.
>Finding
>stuff like that absent context doesn't look at all easy. :/
>
>-- 
>brandon s allbery kf8nh
>allbery.b at gmail.com

-- 
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/20190104/38a5d493/attachment.html>

From ben at smart-cactus.org  Fri Jan  4 18:56:35 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 04 Jan 2019 13:56:35 -0500
Subject: The GHC Proposals Process
In-Reply-To: <CACPahm3oMRR3DXXCM5nSpDAWEjDJBLQ03ow3yNfiuEq-UJB9CQ@mail.gmail.com>
References: <CACPahm3oMRR3DXXCM5nSpDAWEjDJBLQ03ow3yNfiuEq-UJB9CQ@mail.gmail.com>
Message-ID: <B3C228E4-1549-43CE-8977-5F75EEFF7F0C@smart-cactus.org>

On January 4, 2019 12:56:58 PM EST, Ara Adkins <me at ara.io> wrote:
>Hey All,
>
>Now we have our own git instance in GitLab, are there any plans to move
>the
>proposals process from GitHub?
>
>_ara

I haven't considered the possibility of moving the proposal process and I'm not sure I see a compelling reason to do so. I would be happy to consider arguments otherwise but it seems to me that the process is running reasonably well on GitHub and benefits from the broad reach that GitHub provides.

Cheers,

- Ben 

From me at ara.io  Fri Jan  4 19:10:41 2019
From: me at ara.io (Ara Adkins)
Date: Fri, 4 Jan 2019 19:10:41 +0000
Subject: The GHC Proposals Process
In-Reply-To: <B3C228E4-1549-43CE-8977-5F75EEFF7F0C@smart-cactus.org>
References: <CACPahm3oMRR3DXXCM5nSpDAWEjDJBLQ03ow3yNfiuEq-UJB9CQ@mail.gmail.com>
 <B3C228E4-1549-43CE-8977-5F75EEFF7F0C@smart-cactus.org>
Message-ID: <E5E4B4AE-DD6D-454F-87BD-EEC478FF5B06@ara.io>

I certainly have no compelling reasons to do so! It was more a question than anything else, as I happen to agree that the reach of GitHub is beneficial in this case! 

_ara

> On 4 Jan 2019, at 18:56, Ben Gamari <ben at smart-cactus.org> wrote:
> 
>> On January 4, 2019 12:56:58 PM EST, Ara Adkins <me at ara.io> wrote:
>> Hey All,
>> 
>> Now we have our own git instance in GitLab, are there any plans to move
>> the
>> proposals process from GitHub?
>> 
>> _ara
> 
> I haven't considered the possibility of moving the proposal process and I'm not sure I see a compelling reason to do so. I would be happy to consider arguments otherwise but it seems to me that the process is running reasonably well on GitHub and benefits from the broad reach that GitHub provides.
> 
> Cheers,
> 
> - Ben 

From a.pelenitsyn at gmail.com  Fri Jan  4 19:17:45 2019
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Fri, 4 Jan 2019 22:17:45 +0300
Subject: Gitlab pain
In-Reply-To: <B637EC3A-702F-435F-AB07-B38804E8AB06@well-typed.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87tvionvy2.fsf@smart-cactus.org>
 <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>
 <B637EC3A-702F-435F-AB07-B38804E8AB06@well-typed.com>
Message-ID: <CAPKAvQUwso0_o=WvmCZU-BtWgap_VMiNxUEZROvCU_fz_38H+w@mail.gmail.com>

It seems you'd want the "Toggle All" button. There is an issue for that:

https://gitlab.com/gitlab-org/gitlab-ce/issues/19149

There is even a beautiful workaround given there with typing the following
command in the JavaScript console in a browser:
$(".discussion-toggle-button:has(i.fa-chevron-down)").click()
After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
module should reference the symbol") while before I could not.

--
Best, Artem

On Fri, 4 Jan 2019 at 21:48 Ben Gamari <ben at well-typed.com> wrote:

> Quite right. I will bring this up with upstream.
>
> On January 4, 2019 1:04:43 PM EST, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>>
>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> As mentioned by others, discussions that have been marked as "resolved"
>>> are collapsed by default. If you search for the text "Toggle discussion"
>>> you will find that the collapsed discussions have link on their
>>> right-hand side which you can click on to expand the hidden comments.
>>>
>>
>> The problem there being there's a lot of such, and no way to tell which
>> one is relevant unless you have both original links and enough context.
>> Finding stuff like that absent context doesn't look at all easy. :/
>>
>> --
>> brandon s allbery kf8nh
>> allbery.b at gmail.com
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> 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/20190104/d3715040/attachment.html>

From eric at seidel.io  Fri Jan  4 19:19:19 2019
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Jan 2019 14:19:19 -0500
Subject: The GHC Proposals Process
In-Reply-To: <B3C228E4-1549-43CE-8977-5F75EEFF7F0C@smart-cactus.org>
References: <CACPahm3oMRR3DXXCM5nSpDAWEjDJBLQ03ow3yNfiuEq-UJB9CQ@mail.gmail.com>
 <B3C228E4-1549-43CE-8977-5F75EEFF7F0C@smart-cactus.org>
Message-ID: <1546629559.1648668.1625707456.79CA051A@webmail.messagingengine.com>

I've thought about this a little. The only advantage I can think of is that moving to GitLab would make it easier to cross-reference other GHC issues. 

For example, in the record-set-field proposal[1] people have referenced a few different Trac tickets. Sometimes the reference includes a link to the ticket and sometimes it's just "#1234". GitHub (and I hope GitLab) has a nice feature that automatically renders references to other issues as links. It works across projects too, and the comment editor helps you search for the correct issue while typing.

This would be a nice convenience, but I'm not sure if it pulls its weight in comparison to the greater visibility of GitHub.

Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/158

On Fri, Jan 4, 2019, at 13:56, Ben Gamari wrote:
> On January 4, 2019 12:56:58 PM EST, Ara Adkins <me at ara.io> wrote:
> >Hey All,
> >
> >Now we have our own git instance in GitLab, are there any plans to move
> >the
> >proposals process from GitHub?
> >
> >_ara
> 
> I haven't considered the possibility of moving the proposal process and 
> I'm not sure I see a compelling reason to do so. I would be happy to 
> consider arguments otherwise but it seems to me that the process is 
> running reasonably well on GitHub and benefits from the broad reach that 
> GitHub provides.
> 
> Cheers,
> 
> - Ben 
> _______________________________________________
> 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 Jan  4 19:19:26 2019
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 04 Jan 2019 14:19:26 -0500
Subject: Gitlab pain
In-Reply-To: <CAPKAvQUwso0_o=WvmCZU-BtWgap_VMiNxUEZROvCU_fz_38H+w@mail.gmail.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87tvionvy2.fsf@smart-cactus.org>
 <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>
 <B637EC3A-702F-435F-AB07-B38804E8AB06@well-typed.com>
 <CAPKAvQUwso0_o=WvmCZU-BtWgap_VMiNxUEZROvCU_fz_38H+w@mail.gmail.com>
Message-ID: <D39AB54E-9B6F-4882-888F-E19DEAE8B9E0@well-typed.com>



On January 4, 2019 2:17:45 PM EST, Artem Pelenitsyn <a.pelenitsyn at gmail.com> wrote:
>It seems you'd want the "Toggle All" button. There is an issue for
>that:
>
>https://gitlab.com/gitlab-org/gitlab-ce/issues/19149
>

Precisely. Thank you for finding this. 

Cheers, 

- Ben 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From ben at smart-cactus.org  Fri Jan  4 21:33:23 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 04 Jan 2019 16:33:23 -0500
Subject: GitLab cross-posting to Trac?
In-Reply-To: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
Message-ID: <87o98wnm5c.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Hi devs,
>
> With our new GitLab workflow, will commit messages still be posted to
> Issues (once the migration is complete)? That's been really useful
> with Trac.
>
GitLab does not post the commit message to the issues it mentions. It
does create a link to the commit but this doesn't include the commit
message. We could change this with a daemon if we think this would be
helpful.

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/20190104/897451b5/attachment.sig>

From adam at sandbergericsson.se  Fri Jan  4 22:46:00 2019
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Fri, 4 Jan 2019 23:46:00 +0100
Subject: Failure to catch C++ exception in Haskell on OS X
In-Reply-To: <CADLz5wWKkC4yJ=ytOPiuaKh3WYmvw34_bQ-dg5d_0QqyewGnGA@mail.gmail.com>
References: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
 <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>
 <CADLz5wWKkC4yJ=ytOPiuaKh3WYmvw34_bQ-dg5d_0QqyewGnGA@mail.gmail.com>
Message-ID: <E0BB9428-1945-4A87-80CD-61848E25866D@sandbergericsson.se>

A ticket which seems to cover the same problem: https://ghc.haskell.org/trac/ghc/ticket/11829


—Adam

> On 4 Jan 2019, at 16:50, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> 
> On Fri, 4 Jan 2019 at 14:15, Gabor Greif <ggreif at gmail.com> wrote:
>> maybe some DWARF unwind tables are not correctly installed in OS X?
> 
> Hi Gabor, thanks, I will look into that.
> 
>> Do intra-C++ exception catching work in your example?
> 
> Yes, I have a C++ executable foo[1] that links with libfoo that
> correctly catches the exception:
> 
>> $(nix-build --no-link -A foo)/bin/test
>  ...
>  Whoops!
> 
> Since it's working in pure C++ I suspect it has something to do with
> how GHC calls either the C++ compiler or linker.
> 
> Bas
> 
> [1] https://github.com/basvandijk/darwin-cxx-exception-bug/blob/master/foo/test.cpp
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Sat Jan  5 01:31:08 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 5 Jan 2019 01:31:08 +0000
Subject: GitLab cross-posting to Trac?
In-Reply-To: <87o98wnm5c.fsf@smart-cactus.org>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <rae at cs.brynmawr.edu>; GHC <ghc-devs at haskell.org>
| Subject: Re: GitLab cross-posting to Trac?
| 
| Richard Eisenberg <rae at cs.brynmawr.edu> writes:
| 
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
| 
| Cheers,
| 
| - Ben


From v.dijk.bas at gmail.com  Sat Jan  5 02:29:04 2019
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Sat, 5 Jan 2019 03:29:04 +0100
Subject: Failure to catch C++ exception in Haskell on OS X
In-Reply-To: <E0BB9428-1945-4A87-80CD-61848E25866D@sandbergericsson.se>
References: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
 <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>
 <CADLz5wWKkC4yJ=ytOPiuaKh3WYmvw34_bQ-dg5d_0QqyewGnGA@mail.gmail.com>
 <E0BB9428-1945-4A87-80CD-61848E25866D@sandbergericsson.se>
Message-ID: <CADLz5wXOYZYci_6ysUfym-TzEomvqhQbgQ3Bx-HTxpX9e68R8g@mail.gmail.com>

On Fri, 4 Jan 2019 at 23:46, Adam Sandberg Eriksson
<adam at sandbergericsson.se> wrote:
> A ticket which seems to cover the same problem: https://ghc.haskell.org/trac/ghc/ticket/11829

Wonderful! I can confirm[1] that adding the following to the cabal
file fixes the problem:

  if os(darwin)
    ld-options: -Wl,-keep_dwarf_unwind

Shouldn't GHC do this by default when linking on OS X?

Bas

[1] https://github.com/basvandijk/darwin-cxx-exception-bug/commit/9b48441606d2fe364c2a21a4ca8ba6b7ff735fe5

From matthewtpickering at gmail.com  Sat Jan  5 08:47:31 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sat, 5 Jan 2019 08:47:31 +0000
Subject: GitLab cross-posting to Trac?
In-Reply-To: <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>

I really don't think we should emulate trac's behaviour here.

As from now all patches will be merged via gitlab it is unnecessary as
related merge requests show up visually on each ticket and when a
patch is merge the ticket is automatically closed. Ticket numbers
mentioned in commits also create references from tickets to commits so
you can click the hash to see what the commit was.

https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655

On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?
>
> Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.
>
> If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
> | Sent: 04 January 2019 21:33
> | To: Richard Eisenberg <rae at cs.brynmawr.edu>; GHC <ghc-devs at haskell.org>
> | Subject: Re: GitLab cross-posting to Trac?
> |
> | Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> |
> | > Hi devs,
> | >
> | > With our new GitLab workflow, will commit messages still be posted to
> | > Issues (once the migration is complete)? That's been really useful
> | > with Trac.
> | >
> | GitLab does not post the commit message to the issues it mentions. It
> | does create a link to the commit but this doesn't include the commit
> | message. We could change this with a daemon if we think this would be
> | helpful.
> |
> | Cheers,
> |
> | - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From a.pelenitsyn at gmail.com  Sat Jan  5 12:26:07 2019
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Sat, 5 Jan 2019 15:26:07 +0300
Subject: Status of downloads.haskell.org/~ghc/master/
Message-ID: <CAPKAvQUU=4okeRkijyRuc=kmo-h6LdfV3wKS9bLm+DnaZxXWLQ@mail.gmail.com>

Hello devs,

What is the status of this directory [1]? It doesn't seem to be the tip of
the master branch in the repo. In the documentation [2] it says:

> GHC 8.5.20180424 User's Guide

I'm asking because it has broken links to the base haddocks in it (here [3]
try clicking on any link to the library docs, e.g. GHC.Conc.par), and
Google happily indexes and spits out as results of search queries
everything laying here and there, including these pages. Broken links could
lead “outsiders” to a somewhat underwhelming impression of the state of
infrastructure.

[1]: http://downloads.haskell.org/~ghc/master/
[2]: http://downloads.haskell.org/~ghc/master/users-guide/index.html
[3]:
http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html#rts-options-gc

--
Best wishes,
Artem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190105/28d2e1ae/attachment.html>

From simon.jakobi at googlemail.com  Sat Jan  5 13:00:05 2019
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 5 Jan 2019 14:00:05 +0100
Subject: GitLab CI for patches across submodules
Message-ID: <CAGtp2SjVySx7Cs28WFSg1pVeEknuY8iUob=qxRXLdt0j-oeNMQ@mail.gmail.com>

Hi,

I just tried to use GitLab CI to validate a GHC patch including changes to
Haddock: https://gitlab.haskell.org/sjakobi/ghc/pipelines/842

The problem is that the CI script tries to find my Haddock commit at
https://gitlab.haskell.org/ghc/haddock. But that repo doesn't even allow
merge request.

Should the submodule origin for util/haddock maybe point at
https://github.com/haskell/haddock instead?

Cheers,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190105/947e961d/attachment.html>

From rae at cs.brynmawr.edu  Sat Jan  5 16:15:04 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 5 Jan 2019 11:15:04 -0500
Subject: GitLab cross-posting to Trac?
In-Reply-To: <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>
Message-ID: <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>

I second Simon's "super-helpful". But we don't need to exactly copy Trac's behavior. If there is a clear link to the e.g. commit with message, that's fine too.

> On Jan 5, 2019, at 3:47 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> As from now all patches will be merged via gitlab it is unnecessary as
> related merge requests

We're not using GitLab ticketing yet, but I understand we will. When you say "related merge requests", does that include *issues*? GitHub does this, so I imagine it does, but we should make sure. In other words, if we make an MR that references an issue, will the issue show this fact? What if the MR text doesn't reference an issue, but the commit message does? For example, many of my patches are targeted toward one issue, but fix several others on the way. The MR text will probably mention only the main issue, but the commit message will mention the others. Will the others automatically be cross-referenced? Or will I be forced to copy these auxiliary issues into the MR text for proper cross-referencing?

I believe in GitHub, the cross-referencing happens at *mentions*. I think that means we would get it upon posting the MR and upon the use of an issue number in a comment. But does anything happen at a *merge*? That is, suppose the fix for #12345 gets posted and debated at some length. The #12345 issue will get linked to the MR. Then, all is ready and we click the "merge when green" button. Some hours later, the MR is merged. Does the issue get updated then?

> show up visually on each ticket and when a
> patch is merge the ticket is automatically closed.

By "ticket", do you mean issue or MR? I assume you mean MR, and I like this behavior. But I hope you don't mean issue. It's quite common to push a patch materially affecting an issue but not closing it, and I think the manual step to close the issue separately is worthwhile.

> Ticket numbers
> mentioned in commits also create references from tickets to commits so
> you can click the hash to see what the commit was.
> 
> https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655 <https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655>

One small point of nomenclature I'd like to clarify/propose:

- Merge Request (MR): A proposed patch. The new form of a Phab Diff.
- Issue: An infelicity or task to be completed. The new form of a Trac Ticket.
- Ticket: ?. I propose: Either an MR or an issue.

Thanks!
Richard

> 
> On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
> <ghc-devs at haskell.org> wrote:
>> 
>> It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?
>> 
>> Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.
>> 
>> If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)
>> 
>> Thanks
>> 
>> Simon
>> 
>> | -----Original Message-----
>> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
>> | Sent: 04 January 2019 21:33
>> | To: Richard Eisenberg <rae at cs.brynmawr.edu>; GHC <ghc-devs at haskell.org>
>> | Subject: Re: GitLab cross-posting to Trac?
>> |
>> | Richard Eisenberg <rae at cs.brynmawr.edu> writes:
>> |
>> | > Hi devs,
>> | >
>> | > With our new GitLab workflow, will commit messages still be posted to
>> | > Issues (once the migration is complete)? That's been really useful
>> | > with Trac.
>> | >
>> | GitLab does not post the commit message to the issues it mentions. It
>> | does create a link to the commit but this doesn't include the commit
>> | message. We could change this with a daemon if we think this would be
>> | helpful.
>> |
>> | 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/20190105/410cf487/attachment.html>

From simonpj at microsoft.com  Sat Jan  5 17:10:22 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 5 Jan 2019 17:10:22 +0000
Subject: GitLab cross-posting to Trac?
In-Reply-To: <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>
 <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308D853C8B0E580DBD98E5AAD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Thanks Richard - you have put it better than me.

It would be v helpful to have a wiki page summarising all this vocabulary, and how and under what circumstances one thing refers to another.

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 05 January 2019 16:15
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at smart-cactus.org>; GHC <ghc-devs at haskell.org>
Subject: Re: GitLab cross-posting to Trac?

I second Simon's "super-helpful". But we don't need to exactly copy Trac's behavior. If there is a clear link to the e.g. commit with message, that's fine too.


On Jan 5, 2019, at 3:47 AM, Matthew Pickering <matthewtpickering at gmail.com<mailto:matthewtpickering at gmail.com>> wrote:

As from now all patches will be merged via gitlab it is unnecessary as
related merge requests

We're not using GitLab ticketing yet, but I understand we will. When you say "related merge requests", does that include *issues*? GitHub does this, so I imagine it does, but we should make sure. In other words, if we make an MR that references an issue, will the issue show this fact? What if the MR text doesn't reference an issue, but the commit message does? For example, many of my patches are targeted toward one issue, but fix several others on the way. The MR text will probably mention only the main issue, but the commit message will mention the others. Will the others automatically be cross-referenced? Or will I be forced to copy these auxiliary issues into the MR text for proper cross-referencing?

I believe in GitHub, the cross-referencing happens at *mentions*. I think that means we would get it upon posting the MR and upon the use of an issue number in a comment. But does anything happen at a *merge*? That is, suppose the fix for #12345 gets posted and debated at some length. The #12345 issue will get linked to the MR. Then, all is ready and we click the "merge when green" button. Some hours later, the MR is merged. Does the issue get updated then?


show up visually on each ticket and when a
patch is merge the ticket is automatically closed.

By "ticket", do you mean issue or MR? I assume you mean MR, and I like this behavior. But I hope you don't mean issue. It's quite common to push a patch materially affecting an issue but not closing it, and I think the manual step to close the issue separately is worthwhile.


Ticket numbers
mentioned in commits also create references from tickets to commits so
you can click the hash to see what the commit was.

https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgitlab-org%2Fgitlab-ce%2Fissues%2F54621%23note_129031655&data=02%7C01%7Csimonpj%40microsoft.com%7Cafe22b92b7f340e8be9c08d673295f3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823018866115712&sdata=7qFHHV7WwJeNFDRDMP15mU%2BIklGLoso%2BZNorprnD6lU%3D&reserved=0>

One small point of nomenclature I'd like to clarify/propose:

- Merge Request (MR): A proposed patch. The new form of a Phab Diff.
- Issue: An infelicity or task to be completed. The new form of a Trac Ticket.
- Ticket: ?. I propose: Either an MR or an issue.

Thanks!
Richard



On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:


It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit.  Which is terribly painful.  (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>>; GHC <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
| Subject: Re: GitLab cross-posting to Trac?
|
| Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> writes:
|
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
|
| Cheers,
|
| - Ben

_______________________________________________
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

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

From ben at well-typed.com  Sat Jan  5 18:20:20 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 05 Jan 2019 13:20:20 -0500
Subject: GitLab cross-posting to Trac?
In-Reply-To: <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87lg3znezk.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> It's **super-helpful** that the Trac ticket includes, as a comment,
> the commit(s) that fixed it. Please can this happen with Gitlab too?
>
> Otherwise, when looking at the ticket two years later there is
> literally no clue what commit (if any) fixed it.
>
To be clear, GitLab does cross-reference commits and tickets. I
completely agree that this is essential functionality.

What GitLab does not do is show the entire commit message in the
ticket. It merely adds a comment mentioning the SHA of the commit.
This looks something like this [1]:

    Ernestas Kulik mentioned in commit 70166550

I can see that having the text of the commit present in the ticket
itself may have value, however.

Cheers,

- Ben


[1] https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_167754
-------------- 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/20190105/aaa571c0/attachment.sig>

From matthewtpickering at gmail.com  Sat Jan  5 18:50:20 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sat, 5 Jan 2019 18:50:20 +0000
Subject: GitLab cross-posting to Trac?
In-Reply-To: <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>
 <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
Message-ID: <CALuQ0m8vDR8GLbV6JPUNdZ2dapbAcFqQM7ofCtKa4kLMW4CwUA@mail.gmail.com>

> We're not using GitLab ticketing yet, but I understand we will. When you say "related merge requests", does that include *issues*? GitHub does this, so I imagine it does, but we should make sure. In other words, if we make an MR that references an issue, will the issue show this fact? What if the MR text doesn't reference an issue, but the commit message does? For example, many of my patches are targeted toward one issue, but fix several others on the way. The MR text will probably mention only the main issue, but the commit message will mention the others. Will the others automatically be cross-referenced? Or will I be forced to copy these auxiliary issues into the MR text for proper cross-referencing?

If you mention the issue number (#12345) in the MR it will show up as
a mention on the issue.

https://gitlab.gnome.org/GNOME/nautilus/issues/434

If the commit message mentions the issue number then it shows up as a mention.

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_119047

If a comment on another issue mentions an issue number then it shows
up as a mention.

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_117657

>
> I believe in GitHub, the cross-referencing happens at *mentions*. I think that means we would get it upon posting the MR and upon the use of an issue number in a comment. But does anything happen at a *merge*? That is, suppose the fix for #12345 gets posted and debated at some length. The #12345 issue will get linked to the MR. Then, all is ready and we click the "merge when green" button. Some hours later, the MR is merged. Does the issue get updated then?

When a MR is merged and the commit message mentions the issue number
then a mention will be added to the issue which links the issue to the
commit.

https://gitlab.gnome.org/GNOME/nautilus/commit/70166550e89e80e91912b0e7b9bb162073042dba

https://gitlab.gnome.org/GNOME/nautilus/issues/434#note_167754

> By "ticket", do you mean issue or MR? I assume you mean MR, and I like this behavior. But I hope you don't mean issue. It's quite common to push a patch materially affecting an issue but not closing it, and I think the manual step to close the issue separately is worthwhile.

If you write "Closes #12345" in the MR description then when the MR is
merged it will close the issue.

https://docs.gitlab.com/ee/user/project/issues/closing_issues.html#via-merge-request

This, and not much more, is described here:
https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html

Cheers,

Matt

From ben at smart-cactus.org  Sat Jan  5 21:18:23 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 05 Jan 2019 16:18:23 -0500
Subject: GitLab CI for patches across submodules
In-Reply-To: <CAGtp2SjVySx7Cs28WFSg1pVeEknuY8iUob=qxRXLdt0j-oeNMQ@mail.gmail.com>
References: <CAGtp2SjVySx7Cs28WFSg1pVeEknuY8iUob=qxRXLdt0j-oeNMQ@mail.gmail.com>
Message-ID: <87imz2olb8.fsf@smart-cactus.org>

Simon Jakobi via ghc-devs <ghc-devs at haskell.org> writes:

> Hi,
>
> I just tried to use GitLab CI to validate a GHC patch including changes to
> Haddock: https://gitlab.haskell.org/sjakobi/ghc/pipelines/842
>
> The problem is that the CI script tries to find my Haddock commit at
> https://gitlab.haskell.org/ghc/haddock. But that repo doesn't even allow
> merge request.
>
> Should the submodule origin for util/haddock maybe point at
> https://github.com/haskell/haddock instead?
>
In general we want to ensure that only *.haskell.org hosts are relied on
during normal builds (since some users build artifacts under very
restrictive sandbox conditions). However, we can certainly use the
upstream repo during CI builds.

I have opened !78 which should hopefully fix this. Perhaps you could
rebase on topp of this and check?

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/20190105/64ca065a/attachment.sig>

From ben at well-typed.com  Sat Jan  5 22:03:01 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 05 Jan 2019 17:03:01 -0500
Subject: GitLab cross-posting to Trac?
In-Reply-To: <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
References: <C4799ADA-1966-4DC6-83BF-D448AC9EDAC9@cs.brynmawr.edu>
 <87o98wnm5c.fsf@smart-cactus.org>
 <AM0PR83MB0308B6C94B18E31E37C058C5AD8F0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m9NJdKk=kjXNtFVi128Jn7bBjYSox8WbA3Nz8oGxDmUGg@mail.gmail.com>
 <AFDC7AD6-EFCF-42B0-912E-B3CB9E67CD32@cs.brynmawr.edu>
Message-ID: <87ef9qoj8v.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> I second Simon's "super-helpful". But we don't need to exactly copy
> Trac's behavior. If there is a clear link to the e.g. commit with
> message, that's fine too.
>
>> On Jan 5, 2019, at 3:47 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>> 
>> As from now all patches will be merged via gitlab it is unnecessary as
>> related merge requests
>
> We're not using GitLab ticketing yet, but I understand we will. When
> you say "related merge requests", does that include *issues*?
>
> GitHub does this, so I imagine it does, but we should make sure. In
> other words, if we make an MR that references an issue, will the issue
> show this fact? What if the MR text doesn't reference an issue, but
> the commit message does?

In both cases a note will be left on the referenced issue.

> For example, many of my patches are targeted toward one issue, but fix
> several others on the way. The MR text will probably mention only the
> main issue, but the commit message will mention the others. Will the
> others automatically be cross-referenced? Or will I be forced to copy
> these auxiliary issues into the MR text for proper cross-referencing?
>
> I believe in GitHub, the cross-referencing happens at *mentions*.

> I think that means we would get it upon posting the MR and upon the
> use of an issue number in a comment. But does anything happen at a
> *merge*? That is, suppose the fix for #12345 gets posted and debated
> at some length. The #12345 issue will get linked to the MR. Then, all
> is ready and we click the "merge when green" button. Some hours later,
> the MR is merged. Does the issue get updated then?
>
Yes, when the commit is merged to master a note of the form "mentioned
in commit abcde" will appear on the issue. The SHA is a link and the
commit title is shown when one hovers over it.

>> show up visually on each ticket and when a
>> patch is merge the ticket is automatically closed.
>
> By "ticket", do you mean issue or MR? I assume you mean MR, and I like
> this behavior. But I hope you don't mean issue. It's quite common to
> push a patch materially affecting an issue but not closing it, and I
> think the manual step to close the issue separately is worthwhile.
>
By default GitLab can automatically close issues mentioned by a commit
pushed to the `master` branch. However, not all mentioned will result in
closure; rather, only those matching one of a set of patterns [1].

I personally find the default set of patterns a bit scary. For instance,
I found that a commit containing the string "doesn't fix #NNNN" actually
results in #NNNN being closed [2]. For this reason I think we really want to
change or entirely disable [3] this behavior.

[1] https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55970
[3] https://docs.gitlab.com/ee/administration/issue_closing_pattern.html

>> Ticket numbers mentioned in commits also create references from
>> tickets to commits so you can click the hash to see what the commit
>> was.
>> 
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655 <https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655>
>
> One small point of nomenclature I'd like to clarify/propose:
>
> - Merge Request (MR): A proposed patch. The new form of a Phab Diff.
> - Issue: An infelicity or task to be completed. The new form of a Trac Ticket.
> - Ticket: ?. I propose: Either an MR or an issue.
>
Hmm, I generally have used "ticket" and "issue" interchangeably. I
suppose we could repurpose it as you propose; I'm not sure which is less
confusing. In general I think I will probably just avoid using the term
after the migration.

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/20190105/72aa8f1b/attachment.sig>

From ben at smart-cactus.org  Sat Jan  5 22:34:04 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 05 Jan 2019 17:34:04 -0500
Subject: Status of downloads.haskell.org/~ghc/master/
In-Reply-To: <CAPKAvQUU=4okeRkijyRuc=kmo-h6LdfV3wKS9bLm+DnaZxXWLQ@mail.gmail.com>
References: <CAPKAvQUU=4okeRkijyRuc=kmo-h6LdfV3wKS9bLm+DnaZxXWLQ@mail.gmail.com>
Message-ID: <875zv2oht4.fsf@smart-cactus.org>

Artem Pelenitsyn <a.pelenitsyn at gmail.com> writes:

> Hello devs,
>
Hi Artem,

Thanks for bringing this to my attention.

> What is the status of this directory [1]? It doesn't seem to be the tip of
> the master branch in the repo. In the documentation [2] it says:
>
>> GHC 8.5.20180424 User's Guide
>
It is supposed to be maintained by a cron job running on a machine I
have locally. Unfortunately, the cron job proved to be quite a challenge to
keep running reliably and at some point I punted on it until our CI
situation was sorted.

Now since we have proper CI I would like to automate the extraction of a
nightly documentation from the CI tarballs. I have started this in !79.

In the meantime I have kicked off a run of the ad-hoc script to hold us
over until the CI-based solution is merged.

> I'm asking because it has broken links to the base haddocks in it (here [3]
> try clicking on any link to the library docs, e.g. GHC.Conc.par), and
> Google happily indexes and spits out as results of search queries
> everything laying here and there, including these pages. Broken links could
> lead “outsiders” to a somewhat underwhelming impression of the state of
> infrastructure.
>
Hmm, this is indeed surprising. It looks like the problem is a mismatch
between the links produced by Sphinx and those produced by Haddock. I'll
investigate.

For the record, the whole CI-based documentation effort is being tracked
in #14475.

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/20190105/bf63ee57/attachment.sig>

From carter.schonwald at gmail.com  Sat Jan  5 22:46:56 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 5 Jan 2019 17:46:56 -0500
Subject: Failure to catch C++ exception in Haskell on OS X
In-Reply-To: <CADLz5wXOYZYci_6ysUfym-TzEomvqhQbgQ3Bx-HTxpX9e68R8g@mail.gmail.com>
References: <CADLz5wV=eatOYWH-ASkRCRd3SSYAJqsMGNDnGo=5jG=SKNg20w@mail.gmail.com>
 <CAK-hX0ndC+dYjF_6chcbb5+hE3Bb5Qd73LbSjNgYQ6VV96x65g@mail.gmail.com>
 <CADLz5wWKkC4yJ=ytOPiuaKh3WYmvw34_bQ-dg5d_0QqyewGnGA@mail.gmail.com>
 <E0BB9428-1945-4A87-80CD-61848E25866D@sandbergericsson.se>
 <CADLz5wXOYZYci_6ysUfym-TzEomvqhQbgQ3Bx-HTxpX9e68R8g@mail.gmail.com>
Message-ID: <CAHYVw0yHF01aY1gmununqCd4CkWFEB2Wix+31gshYkCYxmiH1g@mail.gmail.com>

Are we talking about Haskell or linking/ calling c plus plus? If the
latter, that’s more of a cabal issue I think?


If you mean ghc build wise
No. The unwind library only supports elf format. Which OS X does not use.

Even that issue aside : ghc currently can’t build with any level of dwarf
enabled on OS X, eg the system linker complains about exceeding some system
section object format limit.

I guess my point is : dwarf data for Haskell libraries on OS X have a few
challenges between here and there.

On Fri, Jan 4, 2019 at 9:29 PM Bas van Dijk <v.dijk.bas at gmail.com> wrote:

> On Fri, 4 Jan 2019 at 23:46, Adam Sandberg Eriksson
> <adam at sandbergericsson.se> wrote:
> > A ticket which seems to cover the same problem:
> https://ghc.haskell.org/trac/ghc/ticket/11829
>
> Wonderful! I can confirm[1] that adding the following to the cabal
> file fixes the problem:
>
>   if os(darwin)
>     ld-options: -Wl,-keep_dwarf_unwind
>
> Shouldn't GHC do this by default when linking on OS X?
>
> Bas
>
> [1]
> https://github.com/basvandijk/darwin-cxx-exception-bug/commit/9b48441606d2fe364c2a21a4ca8ba6b7ff735fe5
> _______________________________________________
> 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/20190105/839069e5/attachment.html>

From nicolas.frisby at gmail.com  Sun Jan  6 04:46:18 2019
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Sat, 5 Jan 2019 20:46:18 -0800
Subject: FYI panic "flatten_args wandered into deeper water than usual"
Message-ID: <CADfHYo6QGSKFxHpDNC0Ok9ArypKT8Fpb1cYz8cu2C0-_oV=bfQ@mail.gmail.com>

While developing a typechecker plugin, I experienced this error message.

> ghc: panic! (the 'impossible' happened)
>   (GHC version 8.6.2 for x86_64-unknown-linux):
> flatten_args wandered into deeper water than usual
>   Call stack:
>       CallStack (from HasCallStack):
>         callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in
ghc:Outputable
>         pprPanic, called at compiler/typecheck/TcFlatten.hs:1331:24 in
ghc:TcFlatten
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I'm sending this email just in case a dev is curious how this panic arises
or if another plugin developer sees the same thing -- the error message is
not very informative, and the corresponding GHC source code is a bit obtuse.

Based on the relevant GHC source code and my recent plugin edits, I was
able to guess correctly that this was due to me generating an extra sort
argument to a promoted datacon. Specifically, I was incorrectly using

> mkTyConApp (promoteDataCon _) [typeKind k,k,...]

instead of just

> mkTyConApp (promoteDataCon _) [k,...]

Thanks! HTH. -Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190105/7dc045c1/attachment.html>

From omeragacan at gmail.com  Sun Jan  6 06:17:44 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 6 Jan 2019 09:17:44 +0300
Subject: Better DWARF info for Cmm procedures?
Message-ID: <CAMQQO3k3eeHkCZ8FSK+NkR-8KmCNWGMfMv0=t-PfTdmtu7-Jbw@mail.gmail.com>

Hi,

Currently debugging Cmm is a bit painful because we don't have enough debug
information to map assembly to Cmm lines, so I have do the mapping manually.
However I realized that when building .cmm files we actually generates some
debug information, in form of "ticks":

    //tick src<rts/Apply.cmm:631:9-37>
    _c2e::I64 = I64[R1 + 32];

Here the tick says that this assignment is for this Cmm line in Apply.cmm:

    Words = StgAP_STACK_size(ap);

I was wondering what needs to be done to generate DWARF information from those
so that gdb can show Cmm line we're executing, and gdb commands like `next`,
`break` etc. work.

I also realize that we don't consistently generate these ticks for all Cmm
lines, for example, in the same Cmm dump there isn't a tick before this line:

    (_c2j::I64) = call MO_Cmpxchg W64(R1, stg_AP_STACK_info,
stg_WHITEHOLE_info);

It's actually for Apply.cmm:646.

So there are two problems:

- Generate ticks for _all_ Cmm lines
- Generate DWARF information from those so that gdb can show current Cmm line,
  and commands like `next` and `break` work.

Anyone know how hard would this be to implement? I'm wondering if we could turn
this into a SoC project. It's a very well defined task, and given that we have
some DWARF support already, perhaps it's not too hard for a SoC.

Ömer

From ben at well-typed.com  Sun Jan  6 11:47:55 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 06 Jan 2019 06:47:55 -0500
Subject: Better DWARF info for Cmm procedures?
In-Reply-To: <CAMQQO3k3eeHkCZ8FSK+NkR-8KmCNWGMfMv0=t-PfTdmtu7-Jbw@mail.gmail.com>
References: <CAMQQO3k3eeHkCZ8FSK+NkR-8KmCNWGMfMv0=t-PfTdmtu7-Jbw@mail.gmail.com>
Message-ID: <87sgy6m2hl.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

> Hi,
>
> Currently debugging Cmm is a bit painful because we don't have enough debug
> information to map assembly to Cmm lines, so I have do the mapping manually.
> However I realized that when building .cmm files we actually generates some
> debug information, in form of "ticks":
>
>     //tick src<rts/Apply.cmm:631:9-37>
>     _c2e::I64 = I64[R1 + 32];
>
> Here the tick says that this assignment is for this Cmm line in Apply.cmm:
>
>     Words = StgAP_STACK_size(ap);
>
> I was wondering what needs to be done to generate DWARF information from those
> so that gdb can show Cmm line we're executing, and gdb commands like `next`,
> `break` etc. work.
>
The DWARF information that we produce are indeed derived from these
source notes. If you compile a C-- module with -g3 you will find the
resulting object file should have line number information.

> I also realize that we don't consistently generate these ticks for all Cmm
> lines, for example, in the same Cmm dump there isn't a tick before this line:
>
Indeed the C-- parser doesn't produce as many source notes
as you might find in C-- from the STG pipeline. Essentially it only adds
source notes on flow control constructs and assignments (see uses of
withSourceNote in CmmParse.y).

However, there is also a slightly more fundamental issue here: GHC's NCG
handles DWARF information with block granularity. Fixing this will be a
bit more involved. See compiler/nativeGen/Dwarf.hs for details.

One alternative would be to just finish debug information in the LLVM
backend and use this instead (originally D2343, although mpickering has
a newer version).

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/20190106/c4a9109b/attachment.sig>

From omeragacan at gmail.com  Sun Jan  6 18:23:39 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 6 Jan 2019 21:23:39 +0300
Subject: Better DWARF info for Cmm procedures?
In-Reply-To: <87sgy6m2hl.fsf@smart-cactus.org>
References: <CAMQQO3k3eeHkCZ8FSK+NkR-8KmCNWGMfMv0=t-PfTdmtu7-Jbw@mail.gmail.com>
 <87sgy6m2hl.fsf@smart-cactus.org>
Message-ID: <CAMQQO3=mJu7Bj36yaxpATVXUctx4xFfd3cjF0Kmw2ezDJLNqBg@mail.gmail.com>

> However, there is also a slightly more fundamental issue here: GHC's NCG
> handles DWARF information with block granularity. Fixing this will be a
> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>
> One alternative would be to just finish debug information in the LLVM
> backend and use this instead (originally D2343, although mpickering has
> a newer version).

But LLVM backend also uses the same debug info we generate for NCG, no? So I
think debug info would still be in block granularity?

How hard do you think it would be to do the refactoring to generate debug info
for each Cmm source line, instead of each RawCmm block?

Ömer

Ben Gamari <ben at well-typed.com>, 6 Oca 2019 Paz, 14:47 tarihinde şunu yazdı:
>
> Ömer Sinan Ağacan <omeragacan at gmail.com> writes:
>
> > Hi,
> >
> > Currently debugging Cmm is a bit painful because we don't have enough debug
> > information to map assembly to Cmm lines, so I have do the mapping manually.
> > However I realized that when building .cmm files we actually generates some
> > debug information, in form of "ticks":
> >
> >     //tick src<rts/Apply.cmm:631:9-37>
> >     _c2e::I64 = I64[R1 + 32];
> >
> > Here the tick says that this assignment is for this Cmm line in Apply.cmm:
> >
> >     Words = StgAP_STACK_size(ap);
> >
> > I was wondering what needs to be done to generate DWARF information from those
> > so that gdb can show Cmm line we're executing, and gdb commands like `next`,
> > `break` etc. work.
> >
> The DWARF information that we produce are indeed derived from these
> source notes. If you compile a C-- module with -g3 you will find the
> resulting object file should have line number information.
>
> > I also realize that we don't consistently generate these ticks for all Cmm
> > lines, for example, in the same Cmm dump there isn't a tick before this line:
> >
> Indeed the C-- parser doesn't produce as many source notes
> as you might find in C-- from the STG pipeline. Essentially it only adds
> source notes on flow control constructs and assignments (see uses of
> withSourceNote in CmmParse.y).
>
> However, there is also a slightly more fundamental issue here: GHC's NCG
> handles DWARF information with block granularity. Fixing this will be a
> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>
> One alternative would be to just finish debug information in the LLVM
> backend and use this instead (originally D2343, although mpickering has
> a newer version).
>
> Cheers,
>
> - Ben

From lonetiger at gmail.com  Sun Jan  6 18:37:17 2019
From: lonetiger at gmail.com (Phyx)
Date: Sun, 6 Jan 2019 18:37:17 +0000
Subject: Blocking a task indefinitely in the RTS
Message-ID: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>

Hi All,

I'm looking for a way to block a task indefinitely until it is woken up by
an external event in both the threaded and non-threaded RTS and returns a
value that was stored/passed. MVar works great for the threaded RTS, but
for the non-threaded there's a bunch of deadlock detection in the scheduler
that would forcibly free the lock and resume the task with an opaque
exception. This means that MVar and anything derived from it is not usable.

STMs are more expensive but also have the same deadlock code. So again no
go. The reason it looks like a deadlock to the RTS is that the "Wake-up"
call in the non-threaded rts will come from C code running inside the RTS.
The RTS essentially just sees all tasks blocked on it's main capability and
(usually rightly so) assumes a deadlock occurred.

You have other states like BlockedOnForeign etc but those are not usable as
a primitive. Previous iterations of I/O managers have each invented
primitives for this such as asyncRead#, but they are not general and can't
be re-used, and requires a different solution for threaded and non-threaded.

I have started making a new primitive IOPort for this, based on the MVar
code, but this is not trivial... (currently I'm getting a segfault
*somewhere* in the primitive's cmm code). The reason is that the semantics
are decidedly different from what MVars guarantee. I should also mention
that this is meant to be internal to base (i.e no exported).

So before I continue down this path and some painful debugging..., does
anyone know of a way to block a task, unblock it later and pass a value
back? It does not need to support anything complicated such as multiple
take/put requests etc.

Cheers,
Tamar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190106/eb90f667/attachment.html>

From simonpj at microsoft.com  Sun Jan  6 21:19:24 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 6 Jan 2019 21:19:24 +0000
Subject: Glasgow Haskell Compiler | Fix #16133 by checking for
 TypeApplications in rnExpr (!77)
In-Reply-To: <merge_request_87@gitlab.haskell.org>
References: <merge_request_87@gitlab.haskell.org>
Message-ID: <AM0PR83MB03080040ACDEE738AA3504B0AD880@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I am now getting lots of email from GitLab, and I’m trying to figure out what they all mean.  They come in various forms.

Here’s one puzzler:

  *   what does the email below mean?  Is it a new merge request?
  *   what is the “!77”?
  *   What does “RyanGlScott/ghc:wip/T16133 → ghc/ghc:master” mean?

Simon

From: Ryan Scott <gitlab at gitlab.haskell.org>
Sent: 05 January 2019 17:46
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Glasgow Haskell Compiler | Fix #16133 by checking for TypeApplications in rnExpr (!77)


Project:Branches: RyanGlScott/ghc:wip/T16133 → ghc/ghc:master

We had a validity check, typeAppErr, for visible kind applications (in rnHsTyKi), but didn't extend the same treatment to visible type applications (in rnExpr). Easily fixed by also invoking typeAppErr from rnExpr.

Fixes https://ghc.haskell.org/trac/ghc/ticket/16133<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fticket%2F16133&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390233674&sdata=1C1YifOb243Ttrz97KqtnAEr9yH0R17qZr0yh%2FgKKRU%3D&reserved=0>.

—
View it on GitLab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F77&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390243688&sdata=bQpVrLN6RrQh%2FsjS026e8uGB%2FRfczQJjU0mYrEkOeU8%3D&reserved=0>.
You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fsent_notifications%2F447feb65a22c202ff644b44f5138d312%2Funsubscribe&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390243688&sdata=xxqzuYyyI4VS%2FsSZ0U10VaYMu9865gAEHDno72uJffw%3D&reserved=0> from this thread or adjust your notification settings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190106/78daa554/attachment.html>

From allbery.b at gmail.com  Sun Jan  6 21:24:57 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 6 Jan 2019 16:24:57 -0500
Subject: Glasgow Haskell Compiler | Fix #16133 by checking for
 TypeApplications in rnExpr (!77)
In-Reply-To: <AM0PR83MB03080040ACDEE738AA3504B0AD880@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_87@gitlab.haskell.org>
 <AM0PR83MB03080040ACDEE738AA3504B0AD880@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAKFCL4Vq1EREQ1yR7CQDESkgwey7ti6eVwUw-r6XZdnDn3CUgw@mail.gmail.com>

For what it's worth, the !77 seems to mean
https://gitlab.haskell.org/ghc/ghc/merge_requests/77 which is also the
"View it on GitLab" link target. And in general the "!" seems to indicate a
merge request, per reference to "!82" mentioning this one. So this does
seem to be a new merge request, and presumably the third part is the
requested merge from a personal WIP branch to master.

On Sun, Jan 6, 2019 at 4:19 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> I am now getting lots of email from GitLab, and I’m trying to figure out
> what they all mean.  They come in various forms.
>
>
>
> Here’s one puzzler:
>
>    - what does the email below mean?  Is it a new merge request?
>    - what is the “!77”?
>    - What does “*RyanGlScott/ghc:wip/T16133 → ghc/ghc:master” *mean?
>
>
>
> Simon
>
>
>
> *From:* Ryan Scott <gitlab at gitlab.haskell.org>
> *Sent:* 05 January 2019 17:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Glasgow Haskell Compiler | Fix #16133 by checking for
> TypeApplications in rnExpr (!77)
>
>
>
> *Project:Branches: RyanGlScott/ghc:wip/T16133 → ghc/ghc:master *
>
> We had a validity check, typeAppErr, for visible *kind* applications (in
> rnHsTyKi), but didn't extend the same treatment to visible *type*
> applications (in rnExpr). Easily fixed by also invoking typeAppErr from
> rnExpr.
>
> Fixes https://ghc.haskell.org/trac/ghc/ticket/16133
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fticket%2F16133&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390233674&sdata=1C1YifOb243Ttrz97KqtnAEr9yH0R17qZr0yh%2FgKKRU%3D&reserved=0>
> .
>
> —
> View it on GitLab
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F77&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390243688&sdata=bQpVrLN6RrQh%2FsjS026e8uGB%2FRfczQJjU0mYrEkOeU8%3D&reserved=0>.
>
> You're receiving this email because of your account on gitlab.haskell.org.
> If you'd like to receive fewer emails, you can unsubscribe
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fsent_notifications%2F447feb65a22c202ff644b44f5138d312%2Funsubscribe&data=02%7C01%7Csimonpj%40microsoft.com%7Cbf82903cc44a4d36b9fc08d673359a05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823071390243688&sdata=xxqzuYyyI4VS%2FsSZ0U10VaYMu9865gAEHDno72uJffw%3D&reserved=0>
> from this thread or adjust your notification settings.
> _______________________________________________
> 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/20190106/d39087c2/attachment.html>

From simon.jakobi at googlemail.com  Sun Jan  6 21:34:18 2019
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sun, 6 Jan 2019 22:34:18 +0100
Subject: GitLab CI for patches across submodules
In-Reply-To: <87imz2olb8.fsf@smart-cactus.org>
References: <CAGtp2SjVySx7Cs28WFSg1pVeEknuY8iUob=qxRXLdt0j-oeNMQ@mail.gmail.com>
 <87imz2olb8.fsf@smart-cactus.org>
Message-ID: <CAGtp2ShMP8tXYei67SrtAc68OA79gkYvWm6oZT+SzNJQOtSsyQ@mail.gmail.com>

Am Sa., 5. Jan. 2019 um 22:18 Uhr schrieb Ben Gamari <ben at smart-cactus.org>:

However, we can certainly use the upstream repo during CI builds.



I have opened !78 which should hopefully fix this. Perhaps you could

rebase on topp of this and check?
>

Thanks, Ben, that works for me.

What I hadn't realized before, is that having my haddock commit in my
Gitlab fork (sjakobi/haddock) apparently also makes it accessible through
ghc/haddock.
What is my-branch in sjakobi/haddock is sjakobi/my-branch in ghc/haddock.

Cheers,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190106/a79d6490/attachment.html>

From rf at rufflewind.com  Sun Jan  6 21:38:10 2019
From: rf at rufflewind.com (Phil Ruffwind)
Date: Sun, 06 Jan 2019 13:38:10 -0800
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
Message-ID: <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>

What if you wrap the MVar in a foreign closure?

    import Control.Concurrent.MVar (newEmptyMVar, putMVar, takeMVar)
    import Control.Exception (bracket)
    import Foreign.Ptr (FunPtr, freeHaskellFunPtr)

    foreign import ccall "wrapper" wrapAwaken :: IO () -> IO (FunPtr (IO ()))

    main = do
      mvar <- newEmptyMVar
      bracket (wrapAwaken (putMVar mvar ())) freeHaskellFunPtr $ \ awaken -> do
        -- giveToExternalCode awaken
        takeMVar mvar

On Sun, Jan 6, 2019, at 10:37, Phyx wrote:
> Hi All,
> 
> I'm looking for a way to block a task indefinitely until it is woken up by
> an external event in both the threaded and non-threaded RTS and returns a
> value that was stored/passed. MVar works great for the threaded RTS, but
> for the non-threaded there's a bunch of deadlock detection in the scheduler
> that would forcibly free the lock and resume the task with an opaque
> exception. This means that MVar and anything derived from it is not usable.
> 
> STMs are more expensive but also have the same deadlock code. So again no
> go. The reason it looks like a deadlock to the RTS is that the "Wake-up"
> call in the non-threaded rts will come from C code running inside the RTS.
> The RTS essentially just sees all tasks blocked on it's main capability and
> (usually rightly so) assumes a deadlock occurred.
> 
> You have other states like BlockedOnForeign etc but those are not usable as
> a primitive. Previous iterations of I/O managers have each invented
> primitives for this such as asyncRead#, but they are not general and can't
> be re-used, and requires a different solution for threaded and non-threaded.
> 
> I have started making a new primitive IOPort for this, based on the MVar
> code, but this is not trivial... (currently I'm getting a segfault
> *somewhere* in the primitive's cmm code). The reason is that the semantics
> are decidedly different from what MVars guarantee. I should also mention
> that this is meant to be internal to base (i.e no exported).
> 
> So before I continue down this path and some painful debugging..., does
> anyone know of a way to block a task, unblock it later and pass a value
> back? It does not need to support anything complicated such as multiple
> take/put requests etc.
> 
> Cheers,
> Tamar
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From jwlato at gmail.com  Mon Jan  7 05:43:50 2019
From: jwlato at gmail.com (John Lato)
Date: Sun, 6 Jan 2019 21:43:50 -0800
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
Message-ID: <CAJ727GitZXDto991nc=qYOr0S=ZRjiDkaMBd4Rx_CVbtQu0Sbw@mail.gmail.com>

Can you use an os-level structure? E.g. block on a file descriptor, socket,
or something like that?

On Sun, Jan 6, 2019, 10:37 Phyx <lonetiger at gmail.com wrote:

> Hi All,
>
> I'm looking for a way to block a task indefinitely until it is woken up by
> an external event in both the threaded and non-threaded RTS and returns a
> value that was stored/passed. MVar works great for the threaded RTS, but
> for the non-threaded there's a bunch of deadlock detection in the scheduler
> that would forcibly free the lock and resume the task with an opaque
> exception. This means that MVar and anything derived from it is not usable.
>
> STMs are more expensive but also have the same deadlock code. So again no
> go. The reason it looks like a deadlock to the RTS is that the "Wake-up"
> call in the non-threaded rts will come from C code running inside the RTS.
> The RTS essentially just sees all tasks blocked on it's main capability and
> (usually rightly so) assumes a deadlock occurred.
>
> You have other states like BlockedOnForeign etc but those are not usable
> as a primitive. Previous iterations of I/O managers have each invented
> primitives for this such as asyncRead#, but they are not general and can't
> be re-used, and requires a different solution for threaded and non-threaded.
>
> I have started making a new primitive IOPort for this, based on the MVar
> code, but this is not trivial... (currently I'm getting a segfault
> *somewhere* in the primitive's cmm code). The reason is that the semantics
> are decidedly different from what MVars guarantee. I should also mention
> that this is meant to be internal to base (i.e no exported).
>
> So before I continue down this path and some painful debugging..., does
> anyone know of a way to block a task, unblock it later and pass a value
> back? It does not need to support anything complicated such as multiple
> take/put requests etc.
>
> Cheers,
> Tamar
> _______________________________________________
> 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/20190106/b2d57b7a/attachment.html>

From ezyang at mit.edu  Mon Jan  7 05:52:29 2019
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 7 Jan 2019 00:52:29 -0500
Subject: How to use Data.Compact.Serialize
In-Reply-To: <CAAJHNPDQLDzgSAQCA4FpMArSxTqzL=Y2B-1FRaxyYCvRXbZ3Pw@mail.gmail.com>
References: <CAAJHNPDQLDzgSAQCA4FpMArSxTqzL=Y2B-1FRaxyYCvRXbZ3Pw@mail.gmail.com>
Message-ID: <1546840306-sup-1569@sabre>

Yes this looks good to me.

It is NOT necessary to statically link libc, since the only pointers
embedded in compact regions are only ever info table pointers, e.g.,
stuff that GHC generated, not arbitrary functions in libc.

Edward

Excerpts from Christopher Done's message of 2018-12-19 10:31:28 +0000:
> Hi,
> 
> On the docs for Data.Compact.Serialize it says:
> 
> http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html
> > Our binary representation contains direct pointers to the info tables
> > of objects in the region. This means that the info tables of the
> > receiving process must be laid out in exactly the same way as from the
> > original process; in practice, this means using static linking, using
> > the exact same binary and turning off ASLR.
> 
> It seems to me that in order to use this module in any practical way
> (i.e. write to file from one process, and then a later run of the
> process reads it), you need to know a special way to build your binary
> which isn't fully described here. What flags, for example, should be
> passed to GHC to make this viable?
> 
> * Turning off ASLR on Linux is done by writing 0 to
>   /proc/sys/kernel/randomize_va_space, which applies to all
>   programs. That's not the most isolated way to deploy an app, but I
>   discovered that you can set this per process here:
>   https://askubuntu.com/a/507954
> * To compile GHC programs statically, use -optl-static -optl-pthread.
> 
> So in total the example would be:
> 
> $ stack build compact
> compact-0.1.0.1: download
> compact-0.1.0.1: configure
> compact-0.1.0.1: build
> compact-0.1.0.1: copy/register
> 
> Example file from docs:
> 
> $ cat main.hs
> {-# LANGUAGE TypeApplications #-}
> import System.Environment
> import Data.Compact
> import Data.Compact.Serialize
> main = do
>   arg:_ <- getArgs
>   case arg of
>     "write" -> do
>       orig_c <- compact ("I want to serialize this", True)
>       writeCompact @(String, Bool) "somefile" orig_c
>     "read" -> do
>       res <- unsafeReadCompact @(String, Bool) "somefile"
>       case res of
>         Left err -> fail err
>         Right c -> print (getCompact c)
> 
> Compiling statically:
> 
> $ stack ghc -- -optl-static -optl-pthread main.hs
> [1 of 1] Compiling Main             ( main.hs, main.o )
> Linking main ...
> [...hundred more warnings like this ...]
> 
> Check that it's static:
> 
> $ ldd main
> not a dynamic executable
> 
> Write the file:
> 
> $ setarch `uname -m` -R ./main write
> 
> Read the file:
> 
> $ setarch `uname -m` -R ./main read
> ("I want to serialize this",True)
> 
> Can a GHC dev confirm that this is the proper way to do this? If so,
> I'll contribute this little example as documentation to the compact package.
> 
> Cheers

From moritz.angermann at gmail.com  Mon Jan  7 06:39:03 2019
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 7 Jan 2019 14:39:03 +0800
Subject: GitLab forks and submodules
Message-ID: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>

Hi *,

so what do we do with submodules? If you point someone to a fork of ghc, say:

  gitlab.haskell.org/foo/ghc

and they try to check it out, they will run into issues because foo didn't clone all the
submodules.  So how is one supposed to clone a forked ghc repository?

Cheers,
 Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190107/db50857c/attachment.sig>

From omeragacan at gmail.com  Mon Jan  7 06:56:52 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 7 Jan 2019 09:56:52 +0300
Subject: Building dictionary terms in Core?
Message-ID: <CAMQQO3mY18FyUKYqNQzu1RjM6-Yi71S4a_tyrASOf82+RHb+-A@mail.gmail.com>

Hi,

In #15646 (recent discussion in Gitlab MR 55) we need dictionary arguments in
Core (in desugarer) to apply to functions like `fromRational :: Fractional a =>
Rational -> a`, but we don't know how to build the dictionary term (`Fractional
a`) in Core. Can anyone who know help us in the MR?

Thanks,

Ömer

From oleg.grenrus at iki.fi  Mon Jan  7 08:00:27 2019
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Mon, 7 Jan 2019 10:00:27 +0200
Subject: Building dictionary terms in Core?
In-Reply-To: <CAMQQO3mY18FyUKYqNQzu1RjM6-Yi71S4a_tyrASOf82+RHb+-A@mail.gmail.com>
References: <CAMQQO3mY18FyUKYqNQzu1RjM6-Yi71S4a_tyrASOf82+RHb+-A@mail.gmail.com>
Message-ID: <2f46a2a1-db79-fed1-de29-9b2bbba0464e@iki.fi>

Hi Ömer,

I cannot answer you precisely, but when I was working on my type-checker
plugin, I used functions `classTyCon` and `tyConSingleDataCon`,
https://github.com/phadej/kleene-type/blob/cb7332b98ae229e162c12186fd4d7fccb06ab62f/plugin/KleenePlugin/TcPlugin.hs#L331-L336;
i.e. shouldn't be much different than constructing a record.

Hopefully those help you find out the right functions.

- Oleg

On 7.1.2019 8.56, Ömer Sinan Ağacan wrote:
> Hi,
>
> In #15646 (recent discussion in Gitlab MR 55) we need dictionary arguments in
> Core (in desugarer) to apply to functions like `fromRational :: Fractional a =>
> Rational -> a`, but we don't know how to build the dictionary term (`Fractional
> a`) in Core. Can anyone who know help us in the MR?
>
> Thanks,
>
> Ömer
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190107/7f2201c4/attachment.sig>

From marlowsd at gmail.com  Mon Jan  7 08:42:14 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 7 Jan 2019 08:42:14 +0000
Subject: [GHC DevOps Group] Welcome to GitLab!
In-Reply-To: <87a7krscvf.fsf@smart-cactus.org>
References: <87a7krscvf.fsf@smart-cactus.org>
Message-ID: <CANsrgP+s4adybpmm+qBWa0tRVxEVQx4C_foQhyF1=YStotjOOA@mail.gmail.com>

Congrats Ben and co! This is a huge step forwards.

On Thu, 27 Dec 2018 at 06:27, Ben Gamari <ben at well-typed.com> wrote:

>
>     git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
>     git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc
>
> This is all that should be necessary; a quick `git pull origin master`
> should verify that everything is working as expected.
>

submodules are still pulling from git.haskell.org, is there an easy way to
fix that?

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190107/d88c5bb6/attachment-0001.html>

From omeragacan at gmail.com  Mon Jan  7 08:54:26 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 7 Jan 2019 11:54:26 +0300
Subject: [GHC DevOps Group] Welcome to GitLab!
In-Reply-To: <CANsrgP+s4adybpmm+qBWa0tRVxEVQx4C_foQhyF1=YStotjOOA@mail.gmail.com>
References: <87a7krscvf.fsf@smart-cactus.org>
 <CANsrgP+s4adybpmm+qBWa0tRVxEVQx4C_foQhyF1=YStotjOOA@mail.gmail.com>
Message-ID: <CAMQQO3ngi=s0SVp0s8hsg0yaxoiBjnDfX-Sn5DWQAraVYooHWw@mail.gmail.com>

> submodules are still pulling from git.haskell.org, is there an easy way to fix that?

`git submodule sync` should fix that.

Ömer

Simon Marlow <marlowsd at gmail.com>, 7 Oca 2019 Pzt, 11:42 tarihinde şunu yazdı:
>
> Congrats Ben and co! This is a huge step forwards.
>
> On Thu, 27 Dec 2018 at 06:27, Ben Gamari <ben at well-typed.com> wrote:
>>
>>
>>     git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
>>     git remote set-url --push origin git at gitlab.haskell.org:ghc/ghc
>>
>> This is all that should be necessary; a quick `git pull origin master`
>> should verify that everything is working as expected.
>
>
> submodules are still pulling from git.haskell.org, is there an easy way to fix that?
>
> Cheers
> Simon
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

From simonpj at microsoft.com  Mon Jan  7 09:12:15 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Jan 2019 09:12:15 +0000
Subject: Building dictionary terms in Core?
In-Reply-To: <CAMQQO3mY18FyUKYqNQzu1RjM6-Yi71S4a_tyrASOf82+RHb+-A@mail.gmail.com>
References: <CAMQQO3mY18FyUKYqNQzu1RjM6-Yi71S4a_tyrASOf82+RHb+-A@mail.gmail.com>
Message-ID: <AM0PR83MB030886C5703A96BDFA545539AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I'm on a train, so unable to dig deep.

The standard thing to do is to build the dictionary in the type checker, and leave it in the syntax tree for the desugarer to use.

The ticket and MR discussion have grown long.  Is there an up-do-date stand-alone description of the currently-proposed design than one can read instead of doing (foldr add-comments empty all-comments)?

Thanks

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
| Agacan
| Sent: 07 January 2019 06:57
| To: ghc-devs <ghc-devs at haskell.org>
| Subject: Building dictionary terms in Core?
| 
| Hi,
| 
| In #15646 (recent discussion in Gitlab MR 55) we need dictionary arguments
| in
| Core (in desugarer) to apply to functions like `fromRational :: Fractional
| a =>
| Rational -> a`, but we don't know how to build the dictionary term
| (`Fractional
| a`) in Core. Can anyone who know help us in the MR?
| 
| Thanks,
| 
| Ömer
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at cs.brynmawr.edu  Mon Jan  7 14:58:40 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 7 Jan 2019 09:58:40 -0500
Subject: FYI panic "flatten_args wandered into deeper water than usual"
In-Reply-To: <CADfHYo6QGSKFxHpDNC0Ok9ArypKT8Fpb1cYz8cu2C0-_oV=bfQ@mail.gmail.com>
References: <CADfHYo6QGSKFxHpDNC0Ok9ArypKT8Fpb1cYz8cu2C0-_oV=bfQ@mail.gmail.com>
Message-ID: <4F3F2944-D639-40B7-9C8C-830B9EB02711@cs.brynmawr.edu>

I suspect that you spent a good deal of time in search of this knowledge.

Is there something in this code that could have helped you do this faster? Unfortunately, the water in flatten_args is indeed deep, and I don't think there's any way to fix that. I've considered writing a peer-reviewed paper just to explain that one function, but decided that no one would care enough to read it (though implementors of other dependently typed languages likely have had to do similar).

Richard

> On Jan 5, 2019, at 11:46 PM, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:
> 
> While developing a typechecker plugin, I experienced this error message.
> 
> > ghc: panic! (the 'impossible' happened)
> >   (GHC version 8.6.2 for x86_64-unknown-linux):
> > 	flatten_args wandered into deeper water than usual
> >   Call stack:
> >       CallStack (from HasCallStack):
> >         callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
> >         pprPanic, called at compiler/typecheck/TcFlatten.hs:1331:24 in ghc:TcFlatten
> > 
> > Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug>
> 
> I'm sending this email just in case a dev is curious how this panic arises or if another plugin developer sees the same thing -- the error message is not very informative, and the corresponding GHC source code is a bit obtuse.
> 
> Based on the relevant GHC source code and my recent plugin edits, I was able to guess correctly that this was due to me generating an extra sort argument to a promoted datacon. Specifically, I was incorrectly using
> 
> > mkTyConApp (promoteDataCon _) [typeKind k,k,...]
> 
> instead of just
> 
> > mkTyConApp (promoteDataCon _) [k,...]
> 
> Thanks! HTH. -Nick
> _______________________________________________
> 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/20190107/b7cceb89/attachment.html>

From ben at well-typed.com  Mon Jan  7 15:32:36 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Jan 2019 10:32:36 -0500
Subject: GitLab forks and submodules
In-Reply-To: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
Message-ID: <87lg3wmqk0.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Hi *,
>
> so what do we do with submodules? If you point someone to a fork of ghc, say:
>
>   gitlab.haskell.org/foo/ghc
>
Indeed submodules have been a constant thorn in our side. We encounter
this same issue during CI jobs on forks. To work around this we have a
script (.gitlab-ci/fix-submodules.py) which tweaks the submodule paths
to point to gitlab.haskell.org/ghc/ghc. Others are free to use this
script locally however it is surely a hack.

I suppose we could just try changing the submodule upstream URLs to
absolute URLs. This would make the (arguably more common) case of
cloning and contributing without submodule changes easier, while making
the case of contributing patches with submodule changes more difficult.

My usual solution is to just clone from ghc/ghc and then add a separate
remote for my fork.

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/20190107/e98708c0/attachment.sig>

From simonpj at microsoft.com  Mon Jan  7 20:35:48 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Jan 2019 20:35:48 +0000
Subject: GitLab forks and submodules
In-Reply-To: <87lg3wmqk0.fsf@smart-cactus.org>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Would it be worth describing this workflow explicitly in our "How to use GitLab for GHC development" page?

S

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
| Sent: 07 January 2019 15:33
| To: Moritz Angermann <moritz.angermann at gmail.com>; ghc-devs <ghc-
| devs at haskell.org>
| Subject: Re: GitLab forks and submodules
| 
| Moritz Angermann <moritz.angermann at gmail.com> writes:
| 
| > Hi *,
| >
| > so what do we do with submodules? If you point someone to a fork of ghc,
| say:
| >
| >   gitlab.haskell.org/foo/ghc
| >
| Indeed submodules have been a constant thorn in our side. We encounter
| this same issue during CI jobs on forks. To work around this we have a
| script (.gitlab-ci/fix-submodules.py) which tweaks the submodule paths
| to point to gitlab.haskell.org/ghc/ghc. Others are free to use this
| script locally however it is surely a hack.
| 
| I suppose we could just try changing the submodule upstream URLs to
| absolute URLs. This would make the (arguably more common) case of
| cloning and contributing without submodule changes easier, while making
| the case of contributing patches with submodule changes more difficult.
| 
| My usual solution is to just clone from ghc/ghc and then add a separate
| remote for my fork.
| 
| Cheers,
| 
| - Ben

From ben at well-typed.com  Mon Jan  7 21:24:20 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Jan 2019 16:24:20 -0500
Subject: GitLab forks and submodules
In-Reply-To: <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87ftu4ma9p.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Would it be worth describing this workflow explicitly in our "How to
> use GitLab for GHC development" page?
>
Yes, indeed it would. I have asked David, who is currently looking at
revising our contributor documentation, to do so.

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/20190107/727c5ce3/attachment.sig>

From ben at well-typed.com  Mon Jan  7 21:28:01 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Jan 2019 16:28:01 -0500
Subject: [GHC DevOps Group] Welcome to GitLab!
In-Reply-To: <CANsrgP+s4adybpmm+qBWa0tRVxEVQx4C_foQhyF1=YStotjOOA@mail.gmail.com>
References: <87a7krscvf.fsf@smart-cactus.org>
 <CANsrgP+s4adybpmm+qBWa0tRVxEVQx4C_foQhyF1=YStotjOOA@mail.gmail.com>
Message-ID: <87bm4sma3m.fsf@smart-cactus.org>

Simon Marlow <marlowsd at gmail.com> writes:

> Congrats Ben and co! This is a huge step forwards.
>
Thanks!

> submodules are still pulling from git.haskell.org, is there an easy way to
> fix that?

Indeed, Omer's advice is spot on.

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/20190107/466f338b/attachment.sig>

From ben at well-typed.com  Mon Jan  7 21:57:01 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Jan 2019 16:57:01 -0500
Subject: Better DWARF info for Cmm procedures?
In-Reply-To: <CAMQQO3=mJu7Bj36yaxpATVXUctx4xFfd3cjF0Kmw2ezDJLNqBg@mail.gmail.com>
References: <CAMQQO3k3eeHkCZ8FSK+NkR-8KmCNWGMfMv0=t-PfTdmtu7-Jbw@mail.gmail.com>
 <87sgy6m2hl.fsf@smart-cactus.org>
 <CAMQQO3=mJu7Bj36yaxpATVXUctx4xFfd3cjF0Kmw2ezDJLNqBg@mail.gmail.com>
Message-ID: <875zv0m8r8.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

>> However, there is also a slightly more fundamental issue here: GHC's NCG
>> handles DWARF information with block granularity. Fixing this will be a
>> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>>
>> One alternative would be to just finish debug information in the LLVM
>> backend and use this instead (originally D2343, although mpickering has
>> a newer version).
>
> But LLVM backend also uses the same debug info we generate for NCG, no? So I
> think debug info would still be in block granularity?
>

> How hard do you think it would be to do the refactoring to generate debug info
> for each Cmm source line, instead of each RawCmm block?
>
I was under the impression that 
the C-- AST can already capture debug information with arbitrarily fine
granularity. However, after looking again at the implementation it looks
like you raise a very good point: CmmTick nodes apparently cover the
entire block they reside within. This is indeed a problem.

I honestly don't know how hard it would be to fix this without serious
surgery to the C-- pipeline. It doesn't sound particularly easy.

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/20190107/9b7172c0/attachment.sig>

From lonetiger at gmail.com  Mon Jan  7 22:09:18 2019
From: lonetiger at gmail.com (Phyx)
Date: Mon, 7 Jan 2019 22:09:18 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
Message-ID: <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>

Hi Phil,

Thanks for the reply, however that just gives me a forced deadlock removal
as before.

new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)
cap 0: thread 1 stopped (blocked on an MVar)
        thread    1 @ 0000000003205388 is blocked on an MVar @
00000000032040c8 (TSO_DIRTY)
deadlocked, forcing major GC...
all threads:
threads on capability 0:
other threads:
        thread    1 @ 0000000003205388 is blocked on an MVar @
00000000032040c8 (TSO_DIRTY)
cap 0: starting GC

I don't believe any solution involving MVars will work for the non-threaded
RTS. Though I'd love to be wrong here...

Regards,
Tamar

On Sun, Jan 6, 2019 at 9:38 PM Phil Ruffwind <rf at rufflewind.com> wrote:

> What if you wrap the MVar in a foreign closure?
>
>     import Control.Concurrent.MVar (newEmptyMVar, putMVar, takeMVar)
>     import Control.Exception (bracket)
>     import Foreign.Ptr (FunPtr, freeHaskellFunPtr)
>
>     foreign import ccall "wrapper" wrapAwaken :: IO () -> IO (FunPtr (IO
> ()))
>
>     main = do
>       mvar <- newEmptyMVar
>       bracket (wrapAwaken (putMVar mvar ())) freeHaskellFunPtr $ \ awaken
> -> do
>         -- giveToExternalCode awaken
>         takeMVar mvar
>
> On Sun, Jan 6, 2019, at 10:37, Phyx wrote:
> > Hi All,
> >
> > I'm looking for a way to block a task indefinitely until it is woken up
> by
> > an external event in both the threaded and non-threaded RTS and returns a
> > value that was stored/passed. MVar works great for the threaded RTS, but
> > for the non-threaded there's a bunch of deadlock detection in the
> scheduler
> > that would forcibly free the lock and resume the task with an opaque
> > exception. This means that MVar and anything derived from it is not
> usable.
> >
> > STMs are more expensive but also have the same deadlock code. So again no
> > go. The reason it looks like a deadlock to the RTS is that the "Wake-up"
> > call in the non-threaded rts will come from C code running inside the
> RTS.
> > The RTS essentially just sees all tasks blocked on it's main capability
> and
> > (usually rightly so) assumes a deadlock occurred.
> >
> > You have other states like BlockedOnForeign etc but those are not usable
> as
> > a primitive. Previous iterations of I/O managers have each invented
> > primitives for this such as asyncRead#, but they are not general and
> can't
> > be re-used, and requires a different solution for threaded and
> non-threaded.
> >
> > I have started making a new primitive IOPort for this, based on the MVar
> > code, but this is not trivial... (currently I'm getting a segfault
> > *somewhere* in the primitive's cmm code). The reason is that the
> semantics
> > are decidedly different from what MVars guarantee. I should also mention
> > that this is meant to be internal to base (i.e no exported).
> >
> > So before I continue down this path and some painful debugging..., does
> > anyone know of a way to block a task, unblock it later and pass a value
> > back? It does not need to support anything complicated such as multiple
> > take/put requests etc.
> >
> > Cheers,
> > Tamar
> > _______________________________________________
> > 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/20190107/cc532d42/attachment.html>

From lonetiger at gmail.com  Mon Jan  7 22:16:51 2019
From: lonetiger at gmail.com (Phyx)
Date: Mon, 7 Jan 2019 22:16:51 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CAJ727GitZXDto991nc=qYOr0S=ZRjiDkaMBd4Rx_CVbtQu0Sbw@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <CAJ727GitZXDto991nc=qYOr0S=ZRjiDkaMBd4Rx_CVbtQu0Sbw@mail.gmail.com>
Message-ID: <CABHktDWRMSC8SKXhTVbEyqzv9KY9chtm0ezKH2gK_XqS90-jGw@mail.gmail.com>

Hi John,

I can, but the only reason that would work is because a blocking foreign
call is except from the
deadlock detection code.  I can't block on the Handle itself as all the I/O
calls are non-blocking for performance reasons.

Instead what I want to do is just pause the current task, which means I
don't have to allocate OS level locks for each task
and have a mutable state for each task, which is essentially what an MVar
does.  My other concern is that using OS primitives
would hit performance a bit, which increases as the load increases. So I'd
much rather do it purely in the Haskell world.

Kind regards,
Tamar

On Mon, Jan 7, 2019 at 5:44 AM John Lato <jwlato at gmail.com> wrote:

> Can you use an os-level structure? E.g. block on a file descriptor,
> socket, or something like that?
>
> On Sun, Jan 6, 2019, 10:37 Phyx <lonetiger at gmail.com wrote:
>
>> Hi All,
>>
>> I'm looking for a way to block a task indefinitely until it is woken up
>> by an external event in both the threaded and non-threaded RTS and returns
>> a value that was stored/passed. MVar works great for the threaded RTS, but
>> for the non-threaded there's a bunch of deadlock detection in the scheduler
>> that would forcibly free the lock and resume the task with an opaque
>> exception. This means that MVar and anything derived from it is not usable.
>>
>> STMs are more expensive but also have the same deadlock code. So again no
>> go. The reason it looks like a deadlock to the RTS is that the "Wake-up"
>> call in the non-threaded rts will come from C code running inside the RTS.
>> The RTS essentially just sees all tasks blocked on it's main capability and
>> (usually rightly so) assumes a deadlock occurred.
>>
>> You have other states like BlockedOnForeign etc but those are not usable
>> as a primitive. Previous iterations of I/O managers have each invented
>> primitives for this such as asyncRead#, but they are not general and can't
>> be re-used, and requires a different solution for threaded and non-threaded.
>>
>> I have started making a new primitive IOPort for this, based on the MVar
>> code, but this is not trivial... (currently I'm getting a segfault
>> *somewhere* in the primitive's cmm code). The reason is that the semantics
>> are decidedly different from what MVars guarantee. I should also mention
>> that this is meant to be internal to base (i.e no exported).
>>
>> So before I continue down this path and some painful debugging..., does
>> anyone know of a way to block a task, unblock it later and pass a value
>> back? It does not need to support anything complicated such as multiple
>> take/put requests etc.
>>
>> Cheers,
>> Tamar
>> _______________________________________________
>> 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/20190107/8921ea5d/attachment.html>

From moritz.angermann at gmail.com  Mon Jan  7 22:22:28 2019
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 8 Jan 2019 06:22:28 +0800
Subject: GitLab forks and submodules
In-Reply-To: <87ftu4ma9p.fsf@smart-cactus.org>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
Message-ID: <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>

Can’t we have absolute submodule paths? Wouldn’t that elevate the issue?

When we all had branches on ghc/ghc this 
was not an issue.

Sent from my iPhone

> On 8 Jan 2019, at 5:24 AM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
> 
>> Would it be worth describing this workflow explicitly in our "How to
>> use GitLab for GHC development" page?
>> 
> Yes, indeed it would. I have asked David, who is currently looking at
> revising our contributor documentation, to do so.
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rf at rufflewind.com  Mon Jan  7 23:23:59 2019
From: rf at rufflewind.com (Phil Ruffwind)
Date: Mon, 07 Jan 2019 15:23:59 -0800
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
Message-ID: <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>

Strange, how could the scheduler assume a deadlock if the MVar could be called from a closure that is still alive?  Can you show the code that you're testing?  

On Mon, Jan 7, 2019, at 14:09, Phyx wrote:
> Hi Phil,
> 
> Thanks for the reply, however that just gives me a forced deadlock removal
> as before.
> 
> new bound thread (1)
> cap 0: schedule()
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (blocked on an MVar)
>         thread    1 @ 0000000003205388 is blocked on an MVar @
> 00000000032040c8 (TSO_DIRTY)
> deadlocked, forcing major GC...
> all threads:
> threads on capability 0:
> other threads:
>         thread    1 @ 0000000003205388 is blocked on an MVar @
> 00000000032040c8 (TSO_DIRTY)
> cap 0: starting GC
> 
> I don't believe any solution involving MVars will work for the non-threaded
> RTS. Though I'd love to be wrong here...
> 
> Regards,
> Tamar

From ggreif at gmail.com  Mon Jan  7 23:28:07 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 8 Jan 2019 00:28:07 +0100
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
Message-ID: <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>

Hi Simon,

a simplifier question...

Roughly a year ago I started learning about imported Ids, their unfoldings etc.

I have very small example program that compiles on Linux.

```haskell
import GHC.Event

main = print evtRead
```

`evtRead` is a newtype-wrapped Int. When you compile above program
with HEAD GHC without optimisation, you'll see that `evtRead` gets
passed directly to `show`.

But with -O1 it's unfolding will be inlined, floated to toplevel, and
dumped as static global data into the using Main module. This was not
the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
the inlining notice that the simplifier gave me (-ddump-inlinings
-dverbose-core2core)

> Inlining done: GHC.Event.Internal.evtRead
>     Inlined fn:  (GHC.Types.I# 1#)
>                  `cast` (Sym (GHC.Event.Internal.N:Event[0])
>                          :: GHC.Types.Coercible GHC.Types.Int
> GHC.Event.Internal.Event)
>     Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
>

I believe this is a regression, as copies of global data can pop up in
potentially many different modules.

What do you think? Which change could have caused this?

Cheers,

    Gabor

From simonpj at microsoft.com  Tue Jan  8 00:00:16 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 00:00:16 +0000
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
Message-ID: <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>

Are you sure?   GHC.Event isn't used on Windows, so I did this:

=================
module Bar where

newtype Evt = Evt Int

evtRead :: Evt
evtRead = Evt 33

instance Show Evt where
  show = showEvt

showEvt :: Evt -> String
{-# NOINLINE showEvt #-}
showEvt (Evt x) = show x
============

module Foo where

import Bar

main = print evtRead
===============

And indeed when I compile these with -O I get

Foo.main1
  = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))

where Bar.evtRead1 is the static (I# 33) box. 

No duplication.

Can you give me a repro case that isn't OS-specific?  (I suppose I can try on Linux tomorrow, but I'm sure that the OS is only accidentally involved here.)

Simon

| -----Original Message-----
| From: Gabor Greif <ggreif at gmail.com>
| Sent: 07 January 2019 23:28
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-devs <ghc-devs at haskell.org>
| Subject: [Q] Inlining done: evtRead
| 
| Hi Simon,
| 
| a simplifier question...
| 
| Roughly a year ago I started learning about imported Ids, their unfoldings
| etc.
| 
| I have very small example program that compiles on Linux.
| 
| ```haskell
| import GHC.Event
| 
| main = print evtRead
| ```
| 
| `evtRead` is a newtype-wrapped Int. When you compile above program
| with HEAD GHC without optimisation, you'll see that `evtRead` gets
| passed directly to `show`.
| 
| But with -O1 it's unfolding will be inlined, floated to toplevel, and
| dumped as static global data into the using Main module. This was not
| the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
| the inlining notice that the simplifier gave me (-ddump-inlinings
| -dverbose-core2core)
| 
| > Inlining done: GHC.Event.Internal.evtRead
| >     Inlined fn:  (GHC.Types.I# 1#)
| >                  `cast` (Sym (GHC.Event.Internal.N:Event[0])
| >                          :: GHC.Types.Coercible GHC.Types.Int
| > GHC.Event.Internal.Event)
| >     Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
| >
| 
| I believe this is a regression, as copies of global data can pop up in
| potentially many different modules.
| 
| What do you think? Which change could have caused this?
| 
| Cheers,
| 
|     Gabor

From ggreif at gmail.com  Tue Jan  8 00:06:18 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 8 Jan 2019 01:06:18 +0100
Subject: [Q] Inlining done: evtRead
In-Reply-To: <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
Message-ID: <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>

I think you have to follow this:

-- | Data is available to be read.
evtRead :: Event
evtRead = Event 1
{-# INLINE evtRead #-}


On 1/8/19, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Are you sure?   GHC.Event isn't used on Windows, so I did this:
>
> =================
> module Bar where
>
> newtype Evt = Evt Int
>
> evtRead :: Evt
> evtRead = Evt 33
>
> instance Show Evt where
>   show = showEvt
>
> showEvt :: Evt -> String
> {-# NOINLINE showEvt #-}
> showEvt (Evt x) = show x
> ============
>
> module Foo where
>
> import Bar
>
> main = print evtRead
> ===============
>
> And indeed when I compile these with -O I get
>
> Foo.main1
>   = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))
>
> where Bar.evtRead1 is the static (I# 33) box.
>
> No duplication.
>
> Can you give me a repro case that isn't OS-specific?  (I suppose I can try
> on Linux tomorrow, but I'm sure that the OS is only accidentally involved
> here.)
>
> Simon
>
> | -----Original Message-----
> | From: Gabor Greif <ggreif at gmail.com>
> | Sent: 07 January 2019 23:28
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: ghc-devs <ghc-devs at haskell.org>
> | Subject: [Q] Inlining done: evtRead
> |
> | Hi Simon,
> |
> | a simplifier question...
> |
> | Roughly a year ago I started learning about imported Ids, their
> unfoldings
> | etc.
> |
> | I have very small example program that compiles on Linux.
> |
> | ```haskell
> | import GHC.Event
> |
> | main = print evtRead
> | ```
> |
> | `evtRead` is a newtype-wrapped Int. When you compile above program
> | with HEAD GHC without optimisation, you'll see that `evtRead` gets
> | passed directly to `show`.
> |
> | But with -O1 it's unfolding will be inlined, floated to toplevel, and
> | dumped as static global data into the using Main module. This was not
> | the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
> | the inlining notice that the simplifier gave me (-ddump-inlinings
> | -dverbose-core2core)
> |
> | > Inlining done: GHC.Event.Internal.evtRead
> | >     Inlined fn:  (GHC.Types.I# 1#)
> | >                  `cast` (Sym (GHC.Event.Internal.N:Event[0])
> | >                          :: GHC.Types.Coercible GHC.Types.Int
> | > GHC.Event.Internal.Event)
> | >     Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
> | >
> |
> | I believe this is a regression, as copies of global data can pop up in
> | potentially many different modules.
> |
> | What do you think? Which change could have caused this?
> |
> | Cheers,
> |
> |     Gabor
>

From simonpj at microsoft.com  Tue Jan  8 00:19:13 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 00:19:13 +0000
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
Message-ID: <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Oh well, your INLINE pragma is saying "please inline evtRead at every call site". And so GHC does exactly that.

That seems like obeying the pragma doesn't it?

Simon

| -----Original Message-----
| From: Gabor Greif <ggreif at gmail.com>
| Sent: 08 January 2019 00:06
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-devs <ghc-devs at haskell.org>
| Subject: Re: [Q] Inlining done: evtRead
| 
| I think you have to follow this:
| 
| -- | Data is available to be read.
| evtRead :: Event
| evtRead = Event 1
| {-# INLINE evtRead #-}
| 
| 
| On 1/8/19, Simon Peyton Jones <simonpj at microsoft.com> wrote:
| > Are you sure?   GHC.Event isn't used on Windows, so I did this:
| >
| > =================
| > module Bar where
| >
| > newtype Evt = Evt Int
| >
| > evtRead :: Evt
| > evtRead = Evt 33
| >
| > instance Show Evt where
| >   show = showEvt
| >
| > showEvt :: Evt -> String
| > {-# NOINLINE showEvt #-}
| > showEvt (Evt x) = show x
| > ============
| >
| > module Foo where
| >
| > import Bar
| >
| > main = print evtRead
| > ===============
| >
| > And indeed when I compile these with -O I get
| >
| > Foo.main1
| >   = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))
| >
| > where Bar.evtRead1 is the static (I# 33) box.
| >
| > No duplication.
| >
| > Can you give me a repro case that isn't OS-specific?  (I suppose I can
| try
| > on Linux tomorrow, but I'm sure that the OS is only accidentally involved
| > here.)
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: Gabor Greif <ggreif at gmail.com>
| > | Sent: 07 January 2019 23:28
| > | To: Simon Peyton Jones <simonpj at microsoft.com>
| > | Cc: ghc-devs <ghc-devs at haskell.org>
| > | Subject: [Q] Inlining done: evtRead
| > |
| > | Hi Simon,
| > |
| > | a simplifier question...
| > |
| > | Roughly a year ago I started learning about imported Ids, their
| > unfoldings
| > | etc.
| > |
| > | I have very small example program that compiles on Linux.
| > |
| > | ```haskell
| > | import GHC.Event
| > |
| > | main = print evtRead
| > | ```
| > |
| > | `evtRead` is a newtype-wrapped Int. When you compile above program
| > | with HEAD GHC without optimisation, you'll see that `evtRead` gets
| > | passed directly to `show`.
| > |
| > | But with -O1 it's unfolding will be inlined, floated to toplevel, and
| > | dumped as static global data into the using Main module. This was not
| > | the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
| > | the inlining notice that the simplifier gave me (-ddump-inlinings
| > | -dverbose-core2core)
| > |
| > | > Inlining done: GHC.Event.Internal.evtRead
| > | >     Inlined fn:  (GHC.Types.I# 1#)
| > | >                  `cast` (Sym (GHC.Event.Internal.N:Event[0])
| > | >                          :: GHC.Types.Coercible GHC.Types.Int
| > | > GHC.Event.Internal.Event)
| > | >     Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
| > | >
| > |
| > | I believe this is a regression, as copies of global data can pop up in
| > | potentially many different modules.
| > |
| > | What do you think? Which change could have caused this?
| > |
| > | Cheers,
| > |
| > |     Gabor
| >

From ggreif at gmail.com  Tue Jan  8 01:10:13 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 8 Jan 2019 02:10:13 +0100
Subject: [Q] Inlining done: evtRead
In-Reply-To: <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
 <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAK-hX0npUmfGrtDfj9acp1s_Lvyc3WcQG-4TT9XscUdLbmek4w@mail.gmail.com>

Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
inliner to respect the pragma?

Thanks and cheers,

    Gabor

On 1/8/19, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Oh well, your INLINE pragma is saying "please inline evtRead at every call
> site". And so GHC does exactly that.
>
> That seems like obeying the pragma doesn't it?
>
> Simon
>
> | -----Original Message-----
> | From: Gabor Greif <ggreif at gmail.com>
> | Sent: 08 January 2019 00:06
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: ghc-devs <ghc-devs at haskell.org>
> | Subject: Re: [Q] Inlining done: evtRead
> |
> | I think you have to follow this:
> |
> | -- | Data is available to be read.
> | evtRead :: Event
> | evtRead = Event 1
> | {-# INLINE evtRead #-}
> |
> |
> | On 1/8/19, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> | > Are you sure?   GHC.Event isn't used on Windows, so I did this:
> | >
> | > =================
> | > module Bar where
> | >
> | > newtype Evt = Evt Int
> | >
> | > evtRead :: Evt
> | > evtRead = Evt 33
> | >
> | > instance Show Evt where
> | >   show = showEvt
> | >
> | > showEvt :: Evt -> String
> | > {-# NOINLINE showEvt #-}
> | > showEvt (Evt x) = show x
> | > ============
> | >
> | > module Foo where
> | >
> | > import Bar
> | >
> | > main = print evtRead
> | > ===============
> | >
> | > And indeed when I compile these with -O I get
> | >
> | > Foo.main1
> | >   = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))
> | >
> | > where Bar.evtRead1 is the static (I# 33) box.
> | >
> | > No duplication.
> | >
> | > Can you give me a repro case that isn't OS-specific?  (I suppose I can
> | try
> | > on Linux tomorrow, but I'm sure that the OS is only accidentally
> involved
> | > here.)
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: Gabor Greif <ggreif at gmail.com>
> | > | Sent: 07 January 2019 23:28
> | > | To: Simon Peyton Jones <simonpj at microsoft.com>
> | > | Cc: ghc-devs <ghc-devs at haskell.org>
> | > | Subject: [Q] Inlining done: evtRead
> | > |
> | > | Hi Simon,
> | > |
> | > | a simplifier question...
> | > |
> | > | Roughly a year ago I started learning about imported Ids, their
> | > unfoldings
> | > | etc.
> | > |
> | > | I have very small example program that compiles on Linux.
> | > |
> | > | ```haskell
> | > | import GHC.Event
> | > |
> | > | main = print evtRead
> | > | ```
> | > |
> | > | `evtRead` is a newtype-wrapped Int. When you compile above program
> | > | with HEAD GHC without optimisation, you'll see that `evtRead` gets
> | > | passed directly to `show`.
> | > |
> | > | But with -O1 it's unfolding will be inlined, floated to toplevel, and
> | > | dumped as static global data into the using Main module. This was not
> | > | the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
> | > | the inlining notice that the simplifier gave me (-ddump-inlinings
> | > | -dverbose-core2core)
> | > |
> | > | > Inlining done: GHC.Event.Internal.evtRead
> | > | >     Inlined fn:  (GHC.Types.I# 1#)
> | > | >                  `cast` (Sym (GHC.Event.Internal.N:Event[0])
> | > | >                          :: GHC.Types.Coercible GHC.Types.Int
> | > | > GHC.Event.Internal.Event)
> | > | >     Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
> | > | >
> | > |
> | > | I believe this is a regression, as copies of global data can pop up
> in
> | > | potentially many different modules.
> | > |
> | > | What do you think? Which change could have caused this?
> | > |
> | > | Cheers,
> | > |
> | > |     Gabor
> | >
>

From ben at well-typed.com  Tue Jan  8 01:52:46 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Jan 2019 20:52:46 -0500
Subject: GitLab forks and submodules
In-Reply-To: <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
Message-ID: <87zhsblxue.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Can’t we have absolute submodule paths? Wouldn’t that elevate the
> issue?
>
Perhaps; I mentioned this possibility in my earlier response. It's not
clear which trade-off is better overall, however.

> When we all had branches on ghc/ghc this 
> was not an issue.
>
As I mention in the documentation, those with commits bits should feel
free to push branches to ghc/ghc.

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/20190107/a4c4af66/attachment-0001.sig>

From omeragacan at gmail.com  Tue Jan  8 05:50:28 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 8 Jan 2019 08:50:28 +0300
Subject: GitLab forks and submodules
In-Reply-To: <87zhsblxue.fsf@smart-cactus.org>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
Message-ID: <CAMQQO3=PLg5_Oy5i31ccsyui+o7Hhh5wWLskYRUxg1Q364EQSg@mail.gmail.com>

&gt; while making the case of contributing patches with submodule changes more
&gt; difficult

I don't understand this, can you give an example of what absolute paths make
harder?

Looking at the wiki pages and scripts we need to make relative paths work for
everyone, I think it's clear that absolute paths would be better because CI
wouldn't need any scripts anymore and users would need no instructions to make
cloning forks work.

Ömer

Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:
>
> Moritz Angermann <moritz.angermann at gmail.com> writes:
>
> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
> > issue?
> >
> Perhaps; I mentioned this possibility in my earlier response. It's not
> clear which trade-off is better overall, however.
>
> > When we all had branches on ghc/ghc this
> > was not an issue.
> >
> As I mention in the documentation, those with commits bits should feel
> free to push branches to ghc/ghc.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From lonetiger at gmail.com  Tue Jan  8 06:22:47 2019
From: lonetiger at gmail.com (Phyx)
Date: Tue, 8 Jan 2019 06:22:47 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
Message-ID: <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>

I have simply copy pasted the code you provided. Note that my actual code
code doesn't pass anything to a foreign interface. It stores everything in
a Haskell mutable object.
The RTS on completion of actions simply schedules a task which inspects
this objects and wakes up as many blocked tasks as possible.

> Strange, how could the scheduler assume a deadlock if the MVar could be
called from a closure that is still alive?  Can you show the code that
you're testing?

Because as far as I can tell, it doesn't care. When it comes to MVars and
STMs the scheduler assumes a deadlock when all tasks on all capabilities
are blocked.
For the threaded runtime it has an early exit condition from this code in
the case where there has been any activity in a complete timeslice or when
you're blocked on
specific calls such as I/O.

On the non-threaded runtime the timeslice case doesn't apply and you only
have one capability, it will force a GC to try to revive some tasks, and if
at the end of
this the tasks are still blocked it will release one in order to attempt to
proceed. In short, as far as I can tell I don't think it considers
reach-ability at all, not for MVars.

This is why things e.g. doing a takeMVar will also process pending puts
etc, so that if you actually enter a blocked state, you know you had no
other choice.

On Mon, Jan 7, 2019 at 11:24 PM Phil Ruffwind <rf at rufflewind.com> wrote:

> Strange, how could the scheduler assume a deadlock if the MVar could be
> called from a closure that is still alive?  Can you show the code that
> you're testing?
>
> On Mon, Jan 7, 2019, at 14:09, Phyx wrote:
> > Hi Phil,
> >
> > Thanks for the reply, however that just gives me a forced deadlock
> removal
> > as before.
> >
> > new bound thread (1)
> > cap 0: schedule()
> > cap 0: running thread 1 (ThreadRunGHC)
> > cap 0: thread 1 stopped (blocked on an MVar)
> >         thread    1 @ 0000000003205388 is blocked on an MVar @
> > 00000000032040c8 (TSO_DIRTY)
> > deadlocked, forcing major GC...
> > all threads:
> > threads on capability 0:
> > other threads:
> >         thread    1 @ 0000000003205388 is blocked on an MVar @
> > 00000000032040c8 (TSO_DIRTY)
> > cap 0: starting GC
> >
> > I don't believe any solution involving MVars will work for the
> non-threaded
> > RTS. Though I'd love to be wrong here...
> >
> > Regards,
> > Tamar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/ce26bea8/attachment.html>

From rf at rufflewind.com  Tue Jan  8 06:59:30 2019
From: rf at rufflewind.com (Phil Ruffwind)
Date: Mon, 07 Jan 2019 22:59:30 -0800
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
Message-ID: <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>

Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :(

> On the non-threaded runtime the timeslice case doesn't apply and you only
> have one capability, it will force a GC to try to revive some tasks, and if
> at the end of
> this the tasks are still blocked it will release one in order to attempt to
> proceed. In short, as far as I can tell I don't think it considers
> reach-ability at all, not for MVars.

Maybe that should be considered a false positive (bug) for the deadlock checker?  Just because the Haskell runtime has a single thread, that doesn't imply the whole program is necessarily single-threaded (in the presence of foreign things).  I'd think this is a legitimate use case for MVars.

From lonetiger at gmail.com  Tue Jan  8 08:11:16 2019
From: lonetiger at gmail.com (Phyx)
Date: Tue, 8 Jan 2019 08:11:16 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
 <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
Message-ID: <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>

> Maybe that should be considered a false positive (bug) for the deadlock
checker?  Just because the Haskell runtime has a single thread, that
doesn't imply the whole program is necessarily single-threaded (in the
presence of foreign things).  I'd think this is a legitimate use case for
MVars.

Perhaps, I can see it both ways really :(. The papers and docs for MVars
put a strong emphasis on this deadlock guarantee (though I've really only
skimmed the paper), taking foreign calls into consideration does somewhat
weaken this of course. I do agree with you that this wasn't the behavior I
expected from MVars and STMs, particularly because they are such low level
building blocks, for instance QSem is constructed with MVar, the docs make
no mention of this but I suspect QSem and the rest all don't do what you'd
expect on the non-threaded RTS.

I did try removing this check to see, but it really didn't like that. It
caused GC to be triggered over and over again as the RTS tried desperately
to find something to do, doesn't seem to consider "do nothing" as a valid
state.

On Tue, Jan 8, 2019 at 6:59 AM Phil Ruffwind <rf at rufflewind.com> wrote:

> Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :(
>
> > On the non-threaded runtime the timeslice case doesn't apply and you only
> > have one capability, it will force a GC to try to revive some tasks, and
> if
> > at the end of
> > this the tasks are still blocked it will release one in order to attempt
> to
> > proceed. In short, as far as I can tell I don't think it considers
> > reach-ability at all, not for MVars.
>
> Maybe that should be considered a false positive (bug) for the deadlock
> checker?  Just because the Haskell runtime has a single thread, that
> doesn't imply the whole program is necessarily single-threaded (in the
> presence of foreign things).  I'd think this is a legitimate use case for
> MVars.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/eef68dc3/attachment.html>

From rf at rufflewind.com  Tue Jan  8 08:23:32 2019
From: rf at rufflewind.com (Phil Ruffwind)
Date: Tue, 08 Jan 2019 00:23:32 -0800
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
 <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
 <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>
Message-ID: <1546935812.2493085.1628526144.1801FD2A@webmail.messagingengine.com>

> I did try removing this check to see, but it really didn't like that. It
> caused GC to be triggered over and over again as the RTS tried desperately
> to find something to do, doesn't seem to consider "do nothing" as a valid
> state.

Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS could use a new intrinsic for blocking on foreign state.

From mikolaj at well-typed.com  Tue Jan  8 08:33:33 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 8 Jan 2019 09:33:33 +0100
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAK-hX0npUmfGrtDfj9acp1s_Lvyc3WcQG-4TT9XscUdLbmek4w@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
 <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAK-hX0npUmfGrtDfj9acp1s_Lvyc3WcQG-4TT9XscUdLbmek4w@mail.gmail.com>
Message-ID: <CAHFo2uq-p+1XbFzjzbk6g9coxwjMyHvTa+AXFYqvxf420MYDMQ@mail.gmail.com>

On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif <ggreif at gmail.com> wrote:
>
> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
> inliner to respect the pragma?

Yes:
https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14

But it's not on 8.6 branch (yet?).

From lonetiger at gmail.com  Tue Jan  8 08:55:51 2019
From: lonetiger at gmail.com (Phyx)
Date: Tue, 8 Jan 2019 08:55:51 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <1546935812.2493085.1628526144.1801FD2A@webmail.messagingengine.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
 <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
 <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>
 <1546935812.2493085.1628526144.1801FD2A@webmail.messagingengine.com>
Message-ID: <CABHktDUsDsLp3naAPgOvoTHW6hhHqc25oBc8rKdkHQE7CAsXrg@mail.gmail.com>

> Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS
could use a new intrinsic for blocking on foreign state

Yeah, that's what I was/am currently working on, "IOPort" has much of the
same property of MVar but doesn't have this deadlock guarantee and only
supports a single put/take at a time.
But debugging CMM is... not fun :( so I was wondering if I was just missing
something with the existing mechanisms.


On Tue, Jan 8, 2019 at 8:23 AM Phil Ruffwind <rf at rufflewind.com> wrote:

> > I did try removing this check to see, but it really didn't like that. It
> > caused GC to be triggered over and over again as the RTS tried
> desperately
> > to find something to do, doesn't seem to consider "do nothing" as a valid
> > state.
>
> Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS
> could use a new intrinsic for blocking on foreign state.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/7356669c/attachment.html>

From omeragacan at gmail.com  Tue Jan  8 08:57:36 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 8 Jan 2019 11:57:36 +0300
Subject: GitLab forks and submodules
In-Reply-To: <87zhsblxue.fsf@smart-cactus.org>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
Message-ID: <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>

> As I mention in the documentation, those with commits bits should feel
> free to push branches to ghc/ghc.

This is sometimes not ideal as it wastes GHC's CI resources. For example I make
a lot of WIP commits to my work branches, and I don't want to keep CI machines
busy for those.

Ömer

Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:
>
> Moritz Angermann <moritz.angermann at gmail.com> writes:
>
> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
> > issue?
> >
> Perhaps; I mentioned this possibility in my earlier response. It's not
> clear which trade-off is better overall, however.
>
> > When we all had branches on ghc/ghc this
> > was not an issue.
> >
> As I mention in the documentation, those with commits bits should feel
> free to push branches to ghc/ghc.
>
> Cheers,
>
> - Ben
> _______________________________________________
> 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 Jan  8 10:00:58 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 10:00:58 +0000
Subject: Reviews
Message-ID: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

When reviewing a MR, I sometimes want to look at (and even add comments to) code that isn't displayed in the MR window.  With Phab there was a "show 20 more lines" link, and even "show the whole file".  How do I do that in GitLab?

When submitting a review, I often want to add an overall comment, not related to  a particular line of code?  How do I do that?

Thanks

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

From ggreif at gmail.com  Tue Jan  8 10:06:01 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 8 Jan 2019 11:06:01 +0100
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAHFo2uq-p+1XbFzjzbk6g9coxwjMyHvTa+AXFYqvxf420MYDMQ@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
 <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAK-hX0npUmfGrtDfj9acp1s_Lvyc3WcQG-4TT9XscUdLbmek4w@mail.gmail.com>
 <CAHFo2uq-p+1XbFzjzbk6g9coxwjMyHvTa+AXFYqvxf420MYDMQ@mail.gmail.com>
Message-ID: <CAK-hX0n9fBLdriiXRoFHX_cOQjHqKDcYWsZgZh+6iXe29g1kKg@mail.gmail.com>

Thanks Mikolaj and Simon,

this explains it. I'll study the related ticket next. Still, the
floating-out related duplication aspect looks like a problem, or would
you disagree? I mean,

a) If the INLINE pragma is such a commandment, why don't we respect it with -O0?
b) Would it be sensible to only inline in scrutinee (`case <id> of
...`) context, to avoid duplication? After all it's the guts of the
value we are interested in, not the whole package.
c) Could a global CSE pass pick up the floated-out value and revert it
to the original imported identifier?
d) Or should be simply remove the INLINE pragmas from the library
(0-ary objects)? Possibly changing to INLINABLE?

Just thinking out loud, as this appears like a pessimisation to me.

Cheers,

    Gabor

On 1/8/19, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
> On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif <ggreif at gmail.com> wrote:
>>
>> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
>> inliner to respect the pragma?
>
> Yes:
> https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14
>
> But it's not on 8.6 branch (yet?).
>

From ggreif at gmail.com  Tue Jan  8 10:09:19 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 8 Jan 2019 11:09:19 +0100
Subject: GitLab forks and submodules
In-Reply-To: <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
Message-ID: <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>

You can specify `[skip ci]` in the commit message if you don't want to
run the pipeline. When you are done, just amend your commit with the
finalised note.

    Gabor

On 1/8/19, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
>> As I mention in the documentation, those with commits bits should feel
>> free to push branches to ghc/ghc.
>
> This is sometimes not ideal as it wastes GHC's CI resources. For example I
> make
> a lot of WIP commits to my work branches, and I don't want to keep CI
> machines
> busy for those.
>
> Ömer
>
> Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:
>>
>> Moritz Angermann <moritz.angermann at gmail.com> writes:
>>
>> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
>> > issue?
>> >
>> Perhaps; I mentioned this possibility in my earlier response. It's not
>> clear which trade-off is better overall, however.
>>
>> > When we all had branches on ghc/ghc this
>> > was not an issue.
>> >
>> As I mention in the documentation, those with commits bits should feel
>> free to push branches to ghc/ghc.
>>
>> 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
>

From simonpj at microsoft.com  Tue Jan  8 10:20:30 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 10:20:30 +0000
Subject: [Q] Inlining done: evtRead
In-Reply-To: <CAK-hX0n9fBLdriiXRoFHX_cOQjHqKDcYWsZgZh+6iXe29g1kKg@mail.gmail.com>
References: <CAK-hX0nx9qYOA_Z7Gs6uSSh7U1TtNwT+S=npCpmopca+7ALVnQ@mail.gmail.com>
 <CAK-hX0=sKcHjEzB04EpgU9Yas7B027H-KbC0Rvx=QP-NuQURdw@mail.gmail.com>
 <AM6PR83MB030929361482BCF3DA457D27AD8A0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAK-hX0kV5i2SDfgjDed3MG+H23Eacw6GuJZzKaDD1XfOpt6Tnw@mail.gmail.com>
 <AM0PR83MB03084CA7E12F45E80C20C5E8AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAK-hX0npUmfGrtDfj9acp1s_Lvyc3WcQG-4TT9XscUdLbmek4w@mail.gmail.com>
 <CAHFo2uq-p+1XbFzjzbk6g9coxwjMyHvTa+AXFYqvxf420MYDMQ@mail.gmail.com>
 <CAK-hX0n9fBLdriiXRoFHX_cOQjHqKDcYWsZgZh+6iXe29g1kKg@mail.gmail.com>
Message-ID: <AM0PR83MB0308EFD0099B73B8AAB07905AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  a) If the INLINE pragma is such a commandment, why don't we respect it with
|  -O0?

We ignore pragmas with -O0.

|  b) Would it be sensible to only inline in scrutinee (`case <id> of
|  ...`) context, to avoid duplication? After all it's the guts of the value
|  we are interested in, not the whole package.

That's what happened before but see Note [Honour INLINE on 0-ary bindings] in CoreUnfold and Trac #15578 

|  c) Could a global CSE pass pick up the floated-out value and revert it to
|  the original imported identifier?

CSE does not currently do CSE with imported unfoldings.  It would be possible, but perhaps expensive, to do so.

|  d) Or should be simply remove the INLINE pragmas from the library (0-ary
|  objects)? Possibly changing to INLINABLE?

I have absolutely no idea why it is there.  I bet that removing it is the right thing to do.

S

|  -----Original Message-----
|  From: Gabor Greif <ggreif at gmail.com>
|  Sent: 08 January 2019 10:06
|  To: Mikolaj Konarski <mikolaj at well-typed.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: [Q] Inlining done: evtRead
|  
|  Thanks Mikolaj and Simon,
|  
|  this explains it. I'll study the related ticket next. Still, the floating-
|  out related duplication aspect looks like a problem, or would you disagree?
|  I mean,
|  
|  a) If the INLINE pragma is such a commandment, why don't we respect it with
|  -O0?
|  b) Would it be sensible to only inline in scrutinee (`case <id> of
|  ...`) context, to avoid duplication? After all it's the guts of the value
|  we are interested in, not the whole package.
|  c) Could a global CSE pass pick up the floated-out value and revert it to
|  the original imported identifier?
|  d) Or should be simply remove the INLINE pragmas from the library (0-ary
|  objects)? Possibly changing to INLINABLE?
|  
|  Just thinking out loud, as this appears like a pessimisation to me.
|  
|  Cheers,
|  
|      Gabor
|  
|  On 1/8/19, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
|  > On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif <ggreif at gmail.com> wrote:
|  >>
|  >> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
|  >> inliner to respect the pragma?
|  >
|  > Yes:
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fcommit%2Fb9b1f99954e69f23e9647d00e048938d
|  > 5509ec14&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca24c2089a67d4377
|  > 39aa08d67550e5a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63682538
|  > 7644348465&amp;sdata=qhyHG6VD1%2B9Mkrjwzt7DcTYFVPhtVosdTdhSCJwExSA%3D&
|  > amp;reserved=0
|  >
|  > But it's not on 8.6 branch (yet?).
|  >

From matthewtpickering at gmail.com  Tue Jan  8 10:32:17 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 8 Jan 2019 10:32:17 +0000
Subject: GitLab forks and submodules
In-Reply-To: <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
 <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>
Message-ID: <CALuQ0m8bBj9N_vJzMpc1rx0E2eT2SvAEMGb0-Lt30U67vNn1Ag@mail.gmail.com>

I agree with Omer that we shouldn't encourage people to push wip branches
to ghc/ghc. It wastes resources and pollutes the repo with lots of branches
that will invariably not be deleted.

I would rather we use absolute paths in the submodule file as I have spent
far longer than I expected trying to get git to use the right submodule in
the past when operating on forks.

Matt

On Tue, 8 Jan 2019, 10:09 Gabor Greif <ggreif at gmail.com wrote:

> You can specify `[skip ci]` in the commit message if you don't want to
> run the pipeline. When you are done, just amend your commit with the
> finalised note.
>
>     Gabor
>
> On 1/8/19, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
> >> As I mention in the documentation, those with commits bits should feel
> >> free to push branches to ghc/ghc.
> >
> > This is sometimes not ideal as it wastes GHC's CI resources. For example
> I
> > make
> > a lot of WIP commits to my work branches, and I don't want to keep CI
> > machines
> > busy for those.
> >
> > Ömer
> >
> > Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu
> yazdı:
> >>
> >> Moritz Angermann <moritz.angermann at gmail.com> writes:
> >>
> >> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
> >> > issue?
> >> >
> >> Perhaps; I mentioned this possibility in my earlier response. It's not
> >> clear which trade-off is better overall, however.
> >>
> >> > When we all had branches on ghc/ghc this
> >> > was not an issue.
> >> >
> >> As I mention in the documentation, those with commits bits should feel
> >> free to push branches to ghc/ghc.
> >>
> >> 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
> >
> _______________________________________________
> 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/20190108/c5367fb4/attachment.html>

From qdunkan at gmail.com  Tue Jan  8 12:48:00 2019
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 8 Jan 2019 20:48:00 +0800
Subject: Reviews
In-Reply-To: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>

On Tue, Jan 8, 2019 at 6:01 PM Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> When reviewing a MR, I sometimes want to look at (and even add comments to) code that isn’t displayed in the MR window.  With Phab there was a “show 20 more lines” link, and even “show the whole file”.  How do I do that in GitLab?

If you click on the gray-ish text on the top and bottom edges of the
displayed greed/red diff areas, it should give you some more lines.

> When submitting a review, I often want to add an overall comment, not related to  a particular line of code?  How do I do that?

I do that by going back to the "Discussion" tab and adding something
at the bottom.

From simonpj at microsoft.com  Tue Jan  8 12:54:52 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 12:54:52 +0000
Subject: Reviews
In-Reply-To: <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
Message-ID: <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  > When submitting a review, I often want to add an overall comment, not
|  related to  a particular line of code?  How do I do that?
|  
|  I do that by going back to the "Discussion" tab and adding something at the
|  bottom.

But alas then it does not form part of the review, landing as a single email. It becomes a separate, disconnected comment.

Simon

|  -----Original Message-----
|  From: Evan Laforge <qdunkan at gmail.com>
|  Sent: 08 January 2019 12:48
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: Reviews
|  
|  On Tue, Jan 8, 2019 at 6:01 PM Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org> wrote:
|  >
|  > When reviewing a MR, I sometimes want to look at (and even add comments
|  to) code that isn’t displayed in the MR window.  With Phab there was a
|  “show 20 more lines” link, and even “show the whole file”.  How do I do
|  that in GitLab?
|  
|  If you click on the gray-ish text on the top and bottom edges of the
|  displayed greed/red diff areas, it should give you some more lines.
|  
|  > When submitting a review, I often want to add an overall comment, not
|  related to  a particular line of code?  How do I do that?
|  
|  I do that by going back to the "Discussion" tab and adding something at the
|  bottom.

From carter.schonwald at gmail.com  Tue Jan  8 15:16:54 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 8 Jan 2019 10:16:54 -0500
Subject: GitLab forks and submodules
In-Reply-To: <CALuQ0m8bBj9N_vJzMpc1rx0E2eT2SvAEMGb0-Lt30U67vNn1Ag@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
 <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>
 <CALuQ0m8bBj9N_vJzMpc1rx0E2eT2SvAEMGb0-Lt30U67vNn1Ag@mail.gmail.com>
Message-ID: <CAHYVw0yVpPjHvkSa59=Z2EzQ2ak0FOM1EoeR96T8QM+g3jvCbw@mail.gmail.com>

Depending on the patch,  the ci feedback may be fundamental.  Eg some of
the native code gen hackery im doing impacts a whole bunch of
configurations I can’t do locally.

We could also have a wip/no-ci prefix ?

Either way it’s certainlu true that we have finite resources and should
endeavor to use them thoughtfully

On Tue, Jan 8, 2019 at 5:32 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> I agree with Omer that we shouldn't encourage people to push wip branches
> to ghc/ghc. It wastes resources and pollutes the repo with lots of branches
> that will invariably not be deleted.
>
> I would rather we use absolute paths in the submodule file as I have spent
> far longer than I expected trying to get git to use the right submodule in
> the past when operating on forks.
>
> Matt
>
>
> On Tue, 8 Jan 2019, 10:09 Gabor Greif <ggreif at gmail.com wrote:
>
>> You can specify `[skip ci]` in the commit message if you don't want to
>> run the pipeline. When you are done, just amend your commit with the
>> finalised note.
>>
>>     Gabor
>>
>> On 1/8/19, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
>> >> As I mention in the documentation, those with commits bits should feel
>> >> free to push branches to ghc/ghc.
>> >
>> > This is sometimes not ideal as it wastes GHC's CI resources. For
>> example I
>> > make
>> > a lot of WIP commits to my work branches, and I don't want to keep CI
>> > machines
>> > busy for those.
>> >
>> > Ömer
>> >
>> > Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu
>> yazdı:
>> >>
>> >> Moritz Angermann <moritz.angermann at gmail.com> writes:
>> >>
>> >> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
>> >> > issue?
>> >> >
>> >> Perhaps; I mentioned this possibility in my earlier response. It's not
>> >> clear which trade-off is better overall, however.
>> >>
>> >> > When we all had branches on ghc/ghc this
>> >> > was not an issue.
>> >> >
>> >> As I mention in the documentation, those with commits bits should feel
>> >> free to push branches to ghc/ghc.
>> >>
>> >> 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
>> >
>> _______________________________________________
>> 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/20190108/dc86284c/attachment.html>

From simonpj at microsoft.com  Tue Jan  8 16:29:16 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 16:29:16 +0000
Subject: Hadrian
Message-ID: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Alp
You've written a helpful wiki page describing how to use Hadrian
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
Could you document where build-products live?  I often look at .hi files.
Could you add

  *   How to do the equivalent of "sh validate"
  *   When validating, how to do things like this:

GhcStage1HcOpts += -DDEBUG -O

GhcStage2HcOpts += -Wwarn -ticky

GhcLibHcOpts +=  -ticky -Wwarn



BUILD_PROF_LIBS = NO



SplitObjs       = YES

HADDOCK_DOCS = NO





BUILD_SPHINX_HTML = NO

BUILD_SPHINX_PDF  = NO

  *   After modifying the source code, how to make stage1 compiler (only). In 'make' it is

$ cd compiler; make 1

  *   After modifying the source code, build the stage2 compiler (only).  In 'make' it is

$ cd compiler; make 2

Perhaps you say  build -freeze1?

  *   In the testsuite, how to use the stage1 compiler

$ make stage=1 TEST=T2543

  *   In nofib, how to build one benchmark, with extra flags, perhaps even with the stage1 compiler

$ make stage=1 EXTRA_HC_OPTS="-ticky -ddump-simpl -ddump-stg"


Thanks!
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/e5ee6546/attachment.html>

From simonpj at microsoft.com  Tue Jan  8 16:30:20 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 16:30:20 +0000
Subject: Gitlab notes
Message-ID: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Friends
I've added a Wiki page to summarise things I've learned about Gitlab.  Please do correct any errors I've made!
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/75de8970/attachment.html>

From iavor.diatchki at gmail.com  Tue Jan  8 18:10:04 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 8 Jan 2019 10:10:04 -0800
Subject: Gitlab notes
In-Reply-To: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>

Hello,

a couple of notes about the use of `git` here, which are probably more
relevant if you collaborate with other people on a branch:

   1. In general, I think that the model is that you create the branch when
you start working on something, and you don't really need
      to do a merge request until later, when you are ready for review.

   2. when you are pushing your branch to the remote (i.e., git-lab), you
probably want to say that you branch should "track" the remote by providing
the `-u` flag:

       git push -u origin wip/spj-wibbles

     This makes `git` remember the association between your local branch,
and the one that lives on git-lab, so later if you can just say `git pull`
and `git push` and
     `git` will know what remote you are talking about.

    3. You shouldn't really force push to a remote, especially if you are
collaborating with other people.
       If you want to integrate your changes with the current HEAD (aka
`master`), you may want to merge it into your working branch.

    4. Once you are finished with the changes and they are ready for
review, you can prepare them by doing any of these as needed:
        a)  rebasing to a more relevant starting point (perhaps even the
current `master`),
        b) squashing commits as necessary---for simple changes, one should
probably end up with a single commit.
      Since those "rewrite history", you are essentially making a new
branch, and you could submit *that* for review.  Alternatively,
      you could reuse your working branch (a bit of a hack), and then you'd
have to "force" push.

    5. When everything is ready for review, then you create the MR for the
appropriate branch (either the new review one, or
        your working one, if you chose to reuse it)

     6. You can continue evolving the branch as usual based on feedback
from the reviews.

     7. Once all the reviewers are happy, you can prepare the branch for
merging with `master` as in 4.

         I believe in the past GHC has tried to maintain a "straight line"
history model, where changes are always made
         on top of the current `master` branch (i.e., there are no visible
merges).  If we are still doing that, then you'd
         have to rebase your reviewed changes on top of `master` in
preparation for merging.

I didn't add this to the wiki, as they are subjective, but they reflect my
understanding of how systems like `git-lab`
are intended to be used.

-Iavor













On Tue, Jan 8, 2019 at 8:30 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> Friends
>
> I’ve added a Wiki page to summarise things I’ve learned about Gitlab.
> Please do correct any errors I’ve made!
>
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ
>
> 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/20190108/42f12a1c/attachment.html>

From carter.schonwald at gmail.com  Tue Jan  8 18:23:55 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 8 Jan 2019 13:23:55 -0500
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CABHktDUsDsLp3naAPgOvoTHW6hhHqc25oBc8rKdkHQE7CAsXrg@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
 <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
 <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>
 <1546935812.2493085.1628526144.1801FD2A@webmail.messagingengine.com>
 <CABHktDUsDsLp3naAPgOvoTHW6hhHqc25oBc8rKdkHQE7CAsXrg@mail.gmail.com>
Message-ID: <CAHYVw0zE2JvVYEYLNvyj4bgYxn07HFJ8SHBvQYOMz1YqitNAHw@mail.gmail.com>

What’s the underlying problem you’re trying to model?

On Tue, Jan 8, 2019 at 3:56 AM Phyx <lonetiger at gmail.com> wrote:

> > Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the
> RTS could use a new intrinsic for blocking on foreign state
>
> Yeah, that's what I was/am currently working on, "IOPort" has much of the
> same property of MVar but doesn't have this deadlock guarantee and only
> supports a single put/take at a time.
> But debugging CMM is... not fun :( so I was wondering if I was just
> missing something with the existing mechanisms.
>
>
> On Tue, Jan 8, 2019 at 8:23 AM Phil Ruffwind <rf at rufflewind.com> wrote:
>
>> > I did try removing this check to see, but it really didn't like that. It
>> > caused GC to be triggered over and over again as the RTS tried
>> desperately
>> > to find something to do, doesn't seem to consider "do nothing" as a
>> valid
>> > state.
>>
>> Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS
>> could use a new intrinsic for blocking on foreign state.
>>
> _______________________________________________
> 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/20190108/bede8ed2/attachment.html>

From simonpj at microsoft.com  Tue Jan  8 18:44:34 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Jan 2019 18:44:34 +0000
Subject: Gitlab notes
In-Reply-To: <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
Message-ID: <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I like your notes.  I’ll add them.

I think that ideally

  *   We’d keep a straight-line history for master
  *   And hence we have to accept force-push to user branches.
  *   Surely we can treat the user branches much as we do HEAD today?  That is, always  pull before pushing; and only force push if you know that you have just pulled; and then rebased, squashed or whatever.
  *   In any case the common case is that only one person is pushing to a user branch

It would be good to agree our normal protocol here.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 08 January 2019 18:10
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Gitlab notes

Hello,

a couple of notes about the use of `git` here, which are probably more relevant if you collaborate with other people on a branch:

   1. In general, I think that the model is that you create the branch when you start working on something, and you don't really need
      to do a merge request until later, when you are ready for review.

   2. when you are pushing your branch to the remote (i.e., git-lab), you probably want to say that you branch should "track" the remote by providing the `-u` flag:

       git push -u origin wip/spj-wibbles

     This makes `git` remember the association between your local branch, and the one that lives on git-lab, so later if you can just say `git pull` and `git push` and
     `git` will know what remote you are talking about.

    3. You shouldn't really force push to a remote, especially if you are collaborating with other people.
       If you want to integrate your changes with the current HEAD (aka `master`), you may want to merge it into your working branch.

    4. Once you are finished with the changes and they are ready for review, you can prepare them by doing any of these as needed:
        a)  rebasing to a more relevant starting point (perhaps even the current `master`),
        b) squashing commits as necessary---for simple changes, one should probably end up with a single commit.
      Since those "rewrite history", you are essentially making a new branch, and you could submit *that* for review.  Alternatively,
      you could reuse your working branch (a bit of a hack), and then you'd have to "force" push.

    5. When everything is ready for review, then you create the MR for the appropriate branch (either the new review one, or
        your working one, if you chose to reuse it)

     6. You can continue evolving the branch as usual based on feedback from the reviews.

     7. Once all the reviewers are happy, you can prepare the branch for merging with `master` as in 4.

         I believe in the past GHC has tried to maintain a "straight line" history model, where changes are always made
         on top of the current `master` branch (i.e., there are no visible merges).  If we are still doing that, then you'd
         have to rebase your reviewed changes on top of `master` in preparation for merging.

I didn't add this to the wiki, as they are subjective, but they reflect my understanding of how systems like `git-lab`
are intended to be used.

-Iavor













On Tue, Jan 8, 2019 at 8:30 AM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
Friends
I’ve added a Wiki page to summarise things I’ve learned about Gitlab.  Please do correct any errors I’ve made!
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FWorkingConventions%2FGitLabSPJ&data=02%7C01%7Csimonpj%40microsoft.com%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183117730&sdata=uwK3NS%2BkQ9RSPRSdzxW1Xm19DsKHlQp2GzV3P6OSODU%3D&reserved=0>
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%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183127722&sdata=3GEN3BxHQzF6s6gv43QYpUu06cjsTxKvOJNgUhdNGxA%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/9aa53493/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Jan  8 19:07:30 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 8 Jan 2019 11:07:30 -0800
Subject: Gitlab notes
In-Reply-To: <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
 <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>

One other thing:

    At least on Github, using the button on the site to merge a request
always creates a proper merge (not a rebase), so the history won't be
straight if we do things that way.  I believe the reasoning is that in this
way, you have record of who did the merging.
    I am not sure if this holds for Gitlab, but we should look into it, if
we want to keep the straight history.




On Tue, Jan 8, 2019 at 10:44 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I like your notes.  I’ll add them.
>
>
>
> I think that ideally
>
>    - We’d keep a straight-line history for master
>    - And hence we have to accept force-push to user branches.
>    - Surely we can treat the user branches much as we do HEAD today?
>    That is, always  pull before pushing; and only force push if you know that
>    you have just pulled; and then rebased, squashed or whatever.
>    - In any case the common case is that only one person is pushing to a
>    user branch
>
>
>
> It would be good to agree our normal protocol here.
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 08 January 2019 18:10
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* Re: Gitlab notes
>
>
>
> Hello,
>
>
>
> a couple of notes about the use of `git` here, which are probably more
> relevant if you collaborate with other people on a branch:
>
>
>
>    1. In general, I think that the model is that you create the branch
> when you start working on something, and you don't really need
>
>       to do a merge request until later, when you are ready for review.
>
>
>
>    2. when you are pushing your branch to the remote (i.e., git-lab), you
> probably want to say that you branch should "track" the remote by providing
> the `-u` flag:
>
>
>
>        git push -u origin wip/spj-wibbles
>
>
>
>      This makes `git` remember the association between your local branch,
> and the one that lives on git-lab, so later if you can just say `git pull`
> and `git push` and
>
>      `git` will know what remote you are talking about.
>
>
>
>     3. You shouldn't really force push to a remote, especially if you are
> collaborating with other people.
>
>        If you want to integrate your changes with the current HEAD (aka
> `master`), you may want to merge it into your working branch.
>
>
>
>     4. Once you are finished with the changes and they are ready for
> review, you can prepare them by doing any of these as needed:
>
>         a)  rebasing to a more relevant starting point (perhaps even the
> current `master`),
>
>         b) squashing commits as necessary---for simple changes, one should
> probably end up with a single commit.
>
>       Since those "rewrite history", you are essentially making a new
> branch, and you could submit *that* for review.  Alternatively,
>
>       you could reuse your working branch (a bit of a hack), and then
> you'd have to "force" push.
>
>
>
>     5. When everything is ready for review, then you create the MR for the
> appropriate branch (either the new review one, or
>
>         your working one, if you chose to reuse it)
>
>
>
>      6. You can continue evolving the branch as usual based on feedback
> from the reviews.
>
>
>
>      7. Once all the reviewers are happy, you can prepare the branch for
> merging with `master` as in 4.
>
>
>
>          I believe in the past GHC has tried to maintain a "straight line"
> history model, where changes are always made
>
>          on top of the current `master` branch (i.e., there are no visible
> merges).  If we are still doing that, then you'd
>
>          have to rebase your reviewed changes on top of `master` in
> preparation for merging.
>
>
>
> I didn't add this to the wiki, as they are subjective, but they reflect my
> understanding of how systems like `git-lab`
>
> are intended to be used.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 8, 2019 at 8:30 AM Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
> Friends
>
> I’ve added a Wiki page to summarise things I’ve learned about Gitlab.
> Please do correct any errors I’ve made!
>
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/GitLabSPJ
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FWorkingConventions%2FGitLabSPJ&data=02%7C01%7Csimonpj%40microsoft.com%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183117730&sdata=uwK3NS%2BkQ9RSPRSdzxW1Xm19DsKHlQp2GzV3P6OSODU%3D&reserved=0>
>
> Thanks
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> 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%7C0f8493cdde724d53f26b08d675948b0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825678183127722&sdata=3GEN3BxHQzF6s6gv43QYpUu06cjsTxKvOJNgUhdNGxA%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/e32ef45c/attachment.html>

From steven at steshaw.org  Wed Jan  9 01:49:18 2019
From: steven at steshaw.org (Steven Shaw)
Date: Wed, 9 Jan 2019 11:49:18 +1000
Subject: Gitlab notes
In-Reply-To: <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
 <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>
Message-ID: <CAMP6nJyVnwfzNvqJ0_DSG4_-8VA0AyomeGcp5pRFDgwZ7-zEXQ@mail.gmail.com>

On Wed, 9 Jan 2019 at 05:07, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> One other thing:
>
>     At least on Github, using the button on the site to merge a request
> always creates a proper merge (not a rebase), so the history won't be
> straight if we do things that way.  I believe the reasoning is that in this
> way, you have record of who did the merging.
>     I am not sure if this holds for Gitlab, but we should look into it, if
> we want to keep the straight history.
>

For GitLab, you can configure 'Fast Forward Merges'. This will then only
allow fast forward merges from the UI.

https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html

I'm not sure if that's been configured for
https://gitlab.haskell.org/ghc/ghc/ as I don't have permission to look at
that.

GitHub also has various options for merging PRs. You might have worked on a
project that only allowed merge commits but you can enable/disable
merge-commit, squash-commits and rebase-commits on GitHub.

Cheers,
Steve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190109/20efcde4/attachment.html>

From ben at smart-cactus.org  Wed Jan  9 04:51:28 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 08 Jan 2019 23:51:28 -0500
Subject: Gitlab notes
In-Reply-To: <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
 <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>
Message-ID: <87lg3ul9h0.fsf@smart-cactus.org>

Iavor Diatchki <iavor.diatchki at gmail.com> writes:

> One other thing:
>
>     At least on Github, using the button on the site to merge a request
> always creates a proper merge (not a rebase), so the history won't be
> straight if we do things that way.  I believe the reasoning is that in this
> way, you have record of who did the merging.

I agree with Simon that the best model for a project like GHC is to
maintain a linear history. Bisection becomes incredibly difficult otherwise.

>     I am not sure if this holds for Gitlab, but we should look into it, if
> we want to keep the straight history.
>
Our GitLab instance is configured to only allow fast-forward merges.
GitLab prompts you to rebase if this isn't possible (even allowing
trivial rebases to be done via the web interface).

- 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/20190108/fc8c7786/attachment.sig>

From lonetiger at gmail.com  Wed Jan  9 06:20:03 2019
From: lonetiger at gmail.com (Phyx)
Date: Wed, 9 Jan 2019 06:20:03 +0000
Subject: Blocking a task indefinitely in the RTS
In-Reply-To: <CAHYVw0zE2JvVYEYLNvyj4bgYxn07HFJ8SHBvQYOMz1YqitNAHw@mail.gmail.com>
References: <CABHktDVZqza=t2NOQtsYjKeBHnQcksB2BX8QUR-xCjA+9HaEkQ@mail.gmail.com>
 <1546810690.2699617.1627108728.585E5684@webmail.messagingengine.com>
 <CABHktDUFfZuNw-AdE2MP5796WW46WJmBk43rq3SpTqcyQW6V+A@mail.gmail.com>
 <1546903439.718495.1628229056.1FF639D5@webmail.messagingengine.com>
 <CABHktDUYXTJzkDRqU3QYhTfMB_vQnj6s9VM_Jf07v0_TjG1zbw@mail.gmail.com>
 <1546930770.2468856.1628482792.49EAA5A0@webmail.messagingengine.com>
 <CABHktDXNtaKNnxDepVM6zYFtsAcYCNopMiuPpB0u+W_HJ8Dczg@mail.gmail.com>
 <1546935812.2493085.1628526144.1801FD2A@webmail.messagingengine.com>
 <CABHktDUsDsLp3naAPgOvoTHW6hhHqc25oBc8rKdkHQE7CAsXrg@mail.gmail.com>
 <CAHYVw0zE2JvVYEYLNvyj4bgYxn07HFJ8SHBvQYOMz1YqitNAHw@mail.gmail.com>
Message-ID: <CABHktDUNWYDeYCnSHLxWOvD=+GsuF0jzWXzRJHyE+3ucfi4AWg@mail.gmail.com>

I'm trying to model an Asynchronous I/O call/interface against a
synchronous Haskell call.
I want the behavior of an unsafe blocking foreign call, without blocking in
the foreign call itself.



On Tue, Jan 8, 2019 at 6:24 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> What’s the underlying problem you’re trying to model?
>
> On Tue, Jan 8, 2019 at 3:56 AM Phyx <lonetiger at gmail.com> wrote:
>
>> > Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the
>> RTS could use a new intrinsic for blocking on foreign state
>>
>> Yeah, that's what I was/am currently working on, "IOPort" has much of the
>> same property of MVar but doesn't have this deadlock guarantee and only
>> supports a single put/take at a time.
>> But debugging CMM is... not fun :( so I was wondering if I was just
>> missing something with the existing mechanisms.
>>
>>
>> On Tue, Jan 8, 2019 at 8:23 AM Phil Ruffwind <rf at rufflewind.com> wrote:
>>
>>> > I did try removing this check to see, but it really didn't like that.
>>> It
>>> > caused GC to be triggered over and over again as the RTS tried
>>> desperately
>>> > to find something to do, doesn't seem to consider "do nothing" as a
>>> valid
>>> > state.
>>>
>>> Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS
>>> could use a new intrinsic for blocking on foreign state.
>>>
>> _______________________________________________
>> 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/20190109/62a998f2/attachment.html>

From alp at well-typed.com  Wed Jan  9 11:10:17 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Wed, 9 Jan 2019 12:10:17 +0100
Subject: Hadrian
In-Reply-To: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <fbda98bb-079f-bdae-4bf8-40692a403017@well-typed.com>

Hello,

A quick note about that 'make.md' document: it's meant as a quick 
reference/cheatsheet (hence the _very_ lightweight format) for people 
familiar with the make build system. Hadrian's README [1] is a better 
place to start from in general and in fact answers or points to 
documents that answer some of your questions. I would perhaps recommend 
that you (and others) wander through that document and any other doc 
that seems relevant to your interests/workflow (e.g testsuite.md, 
user-settings.md in your case)

Hadrian is however currently lacking some knobs that are needed to 
support some of the things you're asking about. None of this implies a 
lot of work and they're all on my TODO. I will certainly make sure to 
post an update once this is taken care of, in addition to augmenting the 
relevant documents of course. For instance, we don't have a 'validate' 
rule at the moment, but we've now got all the pieces we need to write it.

Once I get around to adding those knobs, I'll make sure that all your 
questions are answered in the documentation.

Thanks for your initial feedback on this document!

[1] https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md

On 08/01/2019 17:29, Simon Peyton Jones wrote:
>
> Alp
>
> You’ve written a helpful wiki page describing how to use Hadrian
>
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
>
> Could you document where build-products live?  I often look at .hi files.
>
> Could you add
>
>   * How to do the equivalent of “sh validate”
>   * When validating, how to do things like this:
>
> GhcStage1HcOpts += -DDEBUG -O
>
> GhcStage2HcOpts += -Wwarn -ticky
>
> GhcLibHcOpts +=  -ticky -Wwarn
>
> BUILD_PROF_LIBS = NO
>
> SplitObjs       = YES
>
> HADDOCK_DOCS = NO
>
> BUILD_SPHINX_HTML = NO
>
> BUILD_SPHINX_PDF  = NO
>
>   * After modifying the source code, how to make stage1 compiler
>     (only). In ‘make’ it is
>
> $ cd compiler; make 1
>
>   * After modifying the source code, build the stage2 compiler
>     (only).  In ‘make’ it is
>
> $ cd compiler; make 2
>
> Perhaps you say build –freeze1?
>
>   * In the testsuite, how to use the stage1 compiler
>
> $ make stage=1 TEST=T2543
>
>   * In nofib, how to build one benchmark, with extra flags, perhaps
>     even with the stage1 compiler
>
> $ make stage=1 EXTRA_HC_OPTS=”-ticky -ddump-simpl -ddump-stg”
>
> Thanks!
>
> Simon
>
-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

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

From simonpj at microsoft.com  Wed Jan  9 11:24:01 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Jan 2019 11:24:01 +0000
Subject: Hadrian
In-Reply-To: <fbda98bb-079f-bdae-4bf8-40692a403017@well-typed.com>
References: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <fbda98bb-079f-bdae-4bf8-40692a403017@well-typed.com>
Message-ID: <AM0PR83MB0308C75C74172CCECD1843D9AD8B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

A quick note about that 'make.md' document: it's meant as a quick reference/cheatsheet (hence the _very_ lightweight format) for people familiar with the make build system. Hadrian's README [1] is a better place to start from in general

OK super: can you say that at the start of https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md?

And point to https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md from the more comprehensive page.

So in the end they both refer to each other

S

From: Alp Mestanogullari <alp at well-typed.com>
Sent: 09 January 2019 11:10
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Hadrian


Hello,

A quick note about that 'make.md' document: it's meant as a quick reference/cheatsheet (hence the _very_ lightweight format) for people familiar with the make build system. Hadrian's README [1] is a better place to start from in general and in fact answers or points to documents that answer some of your questions. I would perhaps recommend that you (and others) wander through that document and any other doc that seems relevant to your interests/workflow (e.g testsuite.md, user-settings.md in your case)

Hadrian is however currently lacking some knobs that are needed to support some of the things you're asking about. None of this implies a lot of work and they're all on my TODO. I will certainly make sure to post an update once this is taken care of, in addition to augmenting the relevant documents of course. For instance, we don't have a 'validate' rule at the moment, but we've now got all the pieces we need to write it.

Once I get around to adding those knobs, I'll make sure that all your questions are answered in the documentation.

Thanks for your initial feedback on this document!

[1] https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2FREADME.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=3ujKmq%2Ftj20oEEsTswgP2DRkXJ5bLHFSfGiMmBQKmZo%3D&reserved=0>
On 08/01/2019 17:29, Simon Peyton Jones wrote:
Alp
You've written a helpful wiki page describing how to use Hadrian
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2Fdoc%2Fmake.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=Hbk97%2B6Au9uC9YSWzDvLRDry25x9FxWxTVsgVVALONA%3D&reserved=0>
Could you document where build-products live?  I often look at .hi files.
Could you add

  *   How to do the equivalent of "sh validate"
  *   When validating, how to do things like this:

GhcStage1HcOpts += -DDEBUG -O

GhcStage2HcOpts += -Wwarn -ticky

GhcLibHcOpts +=  -ticky -Wwarn



BUILD_PROF_LIBS = NO



SplitObjs       = YES

HADDOCK_DOCS = NO





BUILD_SPHINX_HTML = NO

BUILD_SPHINX_PDF  = NO

  *   After modifying the source code, how to make stage1 compiler (only). In 'make' it is

$ cd compiler; make 1

  *   After modifying the source code, build the stage2 compiler (only).  In 'make' it is

$ cd compiler; make 2

Perhaps you say  build -freeze1?

  *   In the testsuite, how to use the stage1 compiler

$ make stage=1 TEST=T2543

  *   In nofib, how to build one benchmark, with extra flags, perhaps even with the stage1 compiler

$ make stage=1 EXTRA_HC_OPTS="-ticky -ddump-simpl -ddump-stg"


Thanks!
Simon

--

Alp Mestanogullari, Haskell Consultant

Well-Typed LLP, https://www.well-typed.com/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.well-typed.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225900167&sdata=Oau6Enlm1yNMWM61U%2F8rUIwyTMQubwM3oEGXOQwNAS4%3D&reserved=0>



Registered in England and Wales, OC335890

118 Wymering Mansions, Wymering Road, London, W9 2NF, England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190109/21f98ab6/attachment.html>

From alp at well-typed.com  Wed Jan  9 11:28:16 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Wed, 9 Jan 2019 12:28:16 +0100
Subject: Hadrian
In-Reply-To: <AM0PR83MB0308C75C74172CCECD1843D9AD8B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <fbda98bb-079f-bdae-4bf8-40692a403017@well-typed.com>
 <AM0PR83MB0308C75C74172CCECD1843D9AD8B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <4b50b886-d5f2-f9d2-2645-f67443109cbb@well-typed.com>

Sure thing, I'll push a patch today.

On 09/01/2019 12:24, Simon Peyton Jones wrote:
>
> A quick note about that 'make.md' document: it's meant as a quick 
> reference/cheatsheet (hence the _very_ lightweight format) for people 
> familiar with the make build system. Hadrian's README [1] is a better 
> place to start from in general
>
> OK super: can you say that at the start of 
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md?
>
> And point to 
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md 
> from the more comprehensive page.
>
> So in the end they both refer to each other
>
> S
>
> *From:*Alp Mestanogullari <alp at well-typed.com>
> *Sent:* 09 January 2019 11:10
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* Re: Hadrian
>
> Hello,
>
> A quick note about that 'make.md' document: it's meant as a quick 
> reference/cheatsheet (hence the _very_ lightweight format) for people 
> familiar with the make build system. Hadrian's README [1] is a better 
> place to start from in general and in fact answers or points to 
> documents that answer some of your questions. I would perhaps 
> recommend that you (and others) wander through that document and any 
> other doc that seems relevant to your interests/workflow (e.g 
> testsuite.md, user-settings.md in your case)
>
> Hadrian is however currently lacking some knobs that are needed to 
> support some of the things you're asking about. None of this implies a 
> lot of work and they're all on my TODO. I will certainly make sure to 
> post an update once this is taken care of, in addition to augmenting 
> the relevant documents of course. For instance, we don't have a 
> 'validate' rule at the moment, but we've now got all the pieces we 
> need to write it.
>
> Once I get around to adding those knobs, I'll make sure that all your 
> questions are answered in the documentation.
>
> Thanks for your initial feedback on this document!
>
> [1] https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2FREADME.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=3ujKmq%2Ftj20oEEsTswgP2DRkXJ5bLHFSfGiMmBQKmZo%3D&reserved=0>
>
> On 08/01/2019 17:29, Simon Peyton Jones wrote:
>
>     Alp
>
>     You’ve written a helpful wiki page describing how to use Hadrian
>
>     https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2Fdoc%2Fmake.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=Hbk97%2B6Au9uC9YSWzDvLRDry25x9FxWxTVsgVVALONA%3D&reserved=0>
>
>     Could you document where build-products live?  I often look at .hi
>     files.
>
>     Could you add
>
>       * How to do the equivalent of “sh validate”
>       * When validating, how to do things like this:
>
>     GhcStage1HcOpts += -DDEBUG -O
>
>     GhcStage2HcOpts += -Wwarn -ticky
>
>     GhcLibHcOpts +=  -ticky -Wwarn
>
>     BUILD_PROF_LIBS = NO
>
>     SplitObjs       = YES
>
>     HADDOCK_DOCS = NO
>
>     BUILD_SPHINX_HTML = NO
>
>     BUILD_SPHINX_PDF  = NO
>
>       * After modifying the source code, how to make stage1 compiler
>         (only). In ‘make’ it is
>
>     $ cd compiler; make 1
>
>       * After modifying the source code, build the stage2 compiler
>         (only).  In ‘make’ it is
>
>     $ cd compiler; make 2
>
>     Perhaps you say build –freeze1?
>
>       * In the testsuite, how to use the stage1 compiler
>
>     $ make stage=1 TEST=T2543
>
>       * In nofib, how to build one benchmark, with extra flags,
>         perhaps even with the stage1 compiler
>
>     $ make stage=1 EXTRA_HC_OPTS=”-ticky -ddump-simpl -ddump-stg”
>
>     Thanks!
>
>     Simon
>
> -- 
> Alp Mestanogullari, Haskell Consultant
> Well-Typed LLP,https://www.well-typed.com/  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.well-typed.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225900167&sdata=Oau6Enlm1yNMWM61U%2F8rUIwyTMQubwM3oEGXOQwNAS4%3D&reserved=0>
> Registered in England and Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London, W9 2NF, England

-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190109/2c512d3e/attachment-0001.html>

From alp at well-typed.com  Wed Jan  9 11:54:46 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Wed, 9 Jan 2019 12:54:46 +0100
Subject: Hadrian
In-Reply-To: <4b50b886-d5f2-f9d2-2645-f67443109cbb@well-typed.com>
References: <AM0PR83MB03081122A477F51456D60F41AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <fbda98bb-079f-bdae-4bf8-40692a403017@well-typed.com>
 <AM0PR83MB0308C75C74172CCECD1843D9AD8B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <4b50b886-d5f2-f9d2-2645-f67443109cbb@well-typed.com>
Message-ID: <60e25e4f-d5b3-3ebd-ca72-55b8c90f174f@well-typed.com>

The patch is up on Gitlab: 
https://gitlab.haskell.org/ghc/ghc/merge_requests/96

On 09/01/2019 12:28, Alp Mestanogullari wrote:
>
> Sure thing, I'll push a patch today.
>
> On 09/01/2019 12:24, Simon Peyton Jones wrote:
>>
>> A quick note about that 'make.md' document: it's meant as a quick 
>> reference/cheatsheet (hence the _very_ lightweight format) for people 
>> familiar with the make build system. Hadrian's README [1] is a better 
>> place to start from in general
>>
>> OK super: can you say that at the start of 
>> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md?
>>
>> And point to 
>> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md 
>> from the more comprehensive page.
>>
>> So in the end they both refer to each other
>>
>> S
>>
>> *From:*Alp Mestanogullari <alp at well-typed.com>
>> *Sent:* 09 January 2019 11:10
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* ghc-devs <ghc-devs at haskell.org>
>> *Subject:* Re: Hadrian
>>
>> Hello,
>>
>> A quick note about that 'make.md' document: it's meant as a quick 
>> reference/cheatsheet (hence the _very_ lightweight format) for people 
>> familiar with the make build system. Hadrian's README [1] is a better 
>> place to start from in general and in fact answers or points to 
>> documents that answer some of your questions. I would perhaps 
>> recommend that you (and others) wander through that document and any 
>> other doc that seems relevant to your interests/workflow (e.g 
>> testsuite.md, user-settings.md in your case)
>>
>> Hadrian is however currently lacking some knobs that are needed to 
>> support some of the things you're asking about. None of this implies 
>> a lot of work and they're all on my TODO. I will certainly make sure 
>> to post an update once this is taken care of, in addition to 
>> augmenting the relevant documents of course. For instance, we don't 
>> have a 'validate' rule at the moment, but we've now got all the 
>> pieces we need to write it.
>>
>> Once I get around to adding those knobs, I'll make sure that all your 
>> questions are answered in the documentation.
>>
>> Thanks for your initial feedback on this document!
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2FREADME.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=3ujKmq%2Ftj20oEEsTswgP2DRkXJ5bLHFSfGiMmBQKmZo%3D&reserved=0>
>>
>> On 08/01/2019 17:29, Simon Peyton Jones wrote:
>>
>>     Alp
>>
>>     You’ve written a helpful wiki page describing how to use Hadrian
>>
>>     https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
>>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fhadrian%2Fdoc%2Fmake.md&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225890158&sdata=Hbk97%2B6Au9uC9YSWzDvLRDry25x9FxWxTVsgVVALONA%3D&reserved=0>
>>
>>     Could you document where build-products live?  I often look at
>>     .hi files.
>>
>>     Could you add
>>
>>       * How to do the equivalent of “sh validate”
>>       * When validating, how to do things like this:
>>
>>     GhcStage1HcOpts += -DDEBUG -O
>>
>>     GhcStage2HcOpts += -Wwarn -ticky
>>
>>     GhcLibHcOpts +=  -ticky -Wwarn
>>
>>     BUILD_PROF_LIBS = NO
>>
>>     SplitObjs       = YES
>>
>>     HADDOCK_DOCS = NO
>>
>>     BUILD_SPHINX_HTML = NO
>>
>>     BUILD_SPHINX_PDF  = NO
>>
>>       * After modifying the source code, how to make stage1 compiler
>>         (only). In ‘make’ it is
>>
>>     $ cd compiler; make 1
>>
>>       * After modifying the source code, build the stage2 compiler
>>         (only).  In ‘make’ it is
>>
>>     $ cd compiler; make 2
>>
>>     Perhaps you say build –freeze1?
>>
>>       * In the testsuite, how to use the stage1 compiler
>>
>>     $ make stage=1 TEST=T2543
>>
>>       * In nofib, how to build one benchmark, with extra flags,
>>         perhaps even with the stage1 compiler
>>
>>     $ make stage=1 EXTRA_HC_OPTS=”-ticky -ddump-simpl -ddump-stg”
>>
>>     Thanks!
>>
>>     Simon
>>
>> -- 
>> Alp Mestanogullari, Haskell Consultant
>> Well-Typed LLP,https://www.well-typed.com/  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.well-typed.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3025665679274a8486c808d676230b41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826290225900167&sdata=Oau6Enlm1yNMWM61U%2F8rUIwyTMQubwM3oEGXOQwNAS4%3D&reserved=0>
>> Registered in England and Wales, OC335890
>> 118 Wymering Mansions, Wymering Road, London, W9 2NF, England
> -- 
> Alp Mestanogullari, Haskell Consultant
> Well-Typed LLP,https://www.well-typed.com/
>
> Registered in England and Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London, W9 2NF, England
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

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

From alec.theriault at gmail.com  Wed Jan  9 16:10:48 2019
From: alec.theriault at gmail.com (Alec Theriault)
Date: Wed, 9 Jan 2019 08:10:48 -0800
Subject: Gitlab notes
In-Reply-To: <87lg3ul9h0.fsf@smart-cactus.org>
References: <AM0PR83MB0308B4F191FA1FFE983829EAAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo7Lyf+BLu5cpSwxmk6QM=wkUKmY1wGKXE-6pXKvQWxKw@mail.gmail.com>
 <AM0PR83MB0308FE620A9E7754F5B37A65AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAGK9nuo31tPBKaKQJOQpWXTPrTKsRL5SAQZKpnQo=tzZ66XEiA@mail.gmail.com>
 <87lg3ul9h0.fsf@smart-cactus.org>
Message-ID: <0B6B09CE-2C17-4DEB-951B-D025999550B4@gmail.com>

Hi all,

Could someone sketch out somewhere roughly what the steps are two getting something merged on Gitlab?
Here’s my current understanding:

1. You’ve implemented something and open a MR, CI starts running
2. Looking both at passing CI and at your code, someone with commit bits eventually decides to accept the MR
3. You rebase onto latest master (since we want a linear git history)
4. CI passes again, and your MR ends up in master

However, if someone else finishes step 4 after you start step 3, you’ll need to rebase again (and CI needs to run again), right?
IIRC, Rust solves this with a merge queue (where CI rebases and tests each dequeued PRs, one at a time, merging into master only on successful CI).

I’m all a bit muddled and I’d prefer not to waste the very helpful CI resources. How are things supposed to work?

Thanks,

Alec

> On Jan 8, 2019, at 8:51 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
> 
>> One other thing:
>> 
>>    At least on Github, using the button on the site to merge a request
>> always creates a proper merge (not a rebase), so the history won't be
>> straight if we do things that way.  I believe the reasoning is that in this
>> way, you have record of who did the merging.
> 
> I agree with Simon that the best model for a project like GHC is to
> maintain a linear history. Bisection becomes incredibly difficult otherwise.
> 
>>    I am not sure if this holds for Gitlab, but we should look into it, if
>> we want to keep the straight history.
>> 
> Our GitLab instance is configured to only allow fast-forward merges.
> GitLab prompts you to rebase if this isn't possible (even allowing
> trivial rebases to be done via the web interface).
> 
> - Ben
> _______________________________________________
> 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 Jan 10 10:05:07 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 10 Jan 2019 10:05:07 +0000
Subject: Changes to UserSettings.hs
Message-ID: <CALuQ0m-m_aLsSj_1m1vM9VLtNgmN0d49qOOK965kWcd7uzSNzQ@mail.gmail.com>

Hi all,

Last night my patch got merged which changed some aspects of the
hadrian settings file.

If you have a custom settings file (ie hadrian/UserSettings.hs), you
need to remove reference to the `stage1Only` variable and
add a new variable called `finalStage` which should default to `Stage2`.

https://gitlab.haskell.org/ghc/ghc/commit/6486c6e49c53e75f37ed732b38c5be7ae64785e8#b5b7b63ab5532ca7281d44e164d77f0d56c1fddc

Cheers,

Matt

From qdunkan at gmail.com  Thu Jan 10 11:27:24 2019
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 10 Jan 2019 19:27:24 +0800
Subject: Reviews
In-Reply-To: <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CACbaDy4FDz7=WnRc+AZmcN-wL__GkWkaUpLh=mE7xUS4bm=D6g@mail.gmail.com>

On Tue, Jan 8, 2019 at 8:54 PM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> |  > When submitting a review, I often want to add an overall comment, not
> |  related to  a particular line of code?  How do I do that?
> |
> |  I do that by going back to the "Discussion" tab and adding something at the
> |  bottom.
>
> But alas then it does not form part of the review, landing as a single email. It becomes a separate, disconnected comment.

As far as I can tell, Gitlab doesn't really have a concept of a
review, it's just big pile of disconnected comments... or rather,
they're just all connected to the MR.  But there's no concept of a
"review cycle" except by what you impose by convention.  At work, we
simulate it with assigning to author and reviewer, and the reviewer
signs off by resolving all comments.  Gitlab supports this a bit, it
can prevent you from merging until all comments are resolved, and that
includes the unconnected "discussion" ones.

From moritz.angermann at gmail.com  Thu Jan 10 14:40:52 2019
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 10 Jan 2019 22:40:52 +0800
Subject: GitLab forks and submodules
In-Reply-To: <CAHYVw0yVpPjHvkSa59=Z2EzQ2ak0FOM1EoeR96T8QM+g3jvCbw@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
 <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>
 <CALuQ0m8bBj9N_vJzMpc1rx0E2eT2SvAEMGb0-Lt30U67vNn1Ag@mail.gmail.com>
 <CAHYVw0yVpPjHvkSa59=Z2EzQ2ak0FOM1EoeR96T8QM+g3jvCbw@mail.gmail.com>
Message-ID: <1C1BC502-7FE0-4900-9BD1-B4513B186161@gmail.com>

Alright let me add some example that is really painful with submodules.

Say I have a custom ghc fork angerman/ghc, because I really don't want
to overload CI with all my stupidity and I *know* I'd forget to mark
every commit with [skip ci] or something.

Now I need to modify a bunch of submodules as well, say
- libraries/bytestring
- libraires/unix

And next I want to have someone else collaborate on this with me, either
for testing or contributing or what not.

So I'm going to give them the following commands to run:

git clone --recursive https://gitlab.haskell.org/ghc/ghc
(cd ghc && git remote add angerman https://gitlab.haskell.org/angerman/ghc)
(cd ghc && git fetch --all)
(cd ghc/libraries/bytestring && git remote add angerman https://github.com/angerman/bytestring && git fetch --all)
(cd ghc/libraries/unix && git remote add angerman https://github.com/angerman/unix && git fetch --all)
(cd ghc && git checkout angerman/awesome/sauce)
(cd ghc && git submodule update --init --recursive)

instead of

git clone --recursive https://gitlab.haskell.org/angerman/ghc --branch awesome/sauce

Of course that would require me to change the absolute paths for bytestring and unix
in my repo. So maybe I only need 5 instead of 7 commands to remember to tell, and
type, and ...

Cheers,
 Moritz

> On Jan 8, 2019, at 11:16 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> Depending on the patch,  the ci feedback may be fundamental.  Eg some of the native code gen hackery im doing impacts a whole bunch of configurations I can’t do locally.
> 
> We could also have a wip/no-ci prefix ?
> 
> Either way it’s certainlu true that we have finite resources and should endeavor to use them thoughtfully
> 
> On Tue, Jan 8, 2019 at 5:32 AM Matthew Pickering <matthewtpickering at gmail.com> wrote:
> I agree with Omer that we shouldn't encourage people to push wip branches to ghc/ghc. It wastes resources and pollutes the repo with lots of branches that will invariably not be deleted.
> 
> I would rather we use absolute paths in the submodule file as I have spent far longer than I expected trying to get git to use the right submodule in the past when operating on forks.
> 
> Matt
> 
> 
> On Tue, 8 Jan 2019, 10:09 Gabor Greif <ggreif at gmail.com wrote:
> You can specify `[skip ci]` in the commit message if you don't want to
> run the pipeline. When you are done, just amend your commit with the
> finalised note.
> 
>     Gabor
> 
> On 1/8/19, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
> >> As I mention in the documentation, those with commits bits should feel
> >> free to push branches to ghc/ghc.
> >
> > This is sometimes not ideal as it wastes GHC's CI resources. For example I
> > make
> > a lot of WIP commits to my work branches, and I don't want to keep CI
> > machines
> > busy for those.
> >
> > Ömer
> >
> > Ben Gamari <ben at well-typed.com>, 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:
> >>
> >> Moritz Angermann <moritz.angermann at gmail.com> writes:
> >>
> >> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
> >> > issue?
> >> >
> >> Perhaps; I mentioned this possibility in my earlier response. It's not
> >> clear which trade-off is better overall, however.
> >>
> >> > When we all had branches on ghc/ghc this
> >> > was not an issue.
> >> >
> >> As I mention in the documentation, those with commits bits should feel
> >> free to push branches to ghc/ghc.
> >>
> >> 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
> >
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190110/a88e1b74/attachment.sig>

From simonpj at microsoft.com  Thu Jan 10 17:16:05 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Jan 2019 17:16:05 +0000
Subject: More GitLab questions
Message-ID: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>

  *   When looking at a comment on a MR, I see some snippet of code.  How can I see what module that snippet is in?  Apart from scrolling up to find the file header - being careful not to miss it and scroll into the previous file.
  *   When looking a comment, there's a little button to skip to the next unresolved comment.  Good.  But if I respond to the comment (without resolving it), that little button disappears. How can I find the next unresolved comment?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190110/072c4a5f/attachment.html>

From ben at well-typed.com  Thu Jan 10 17:17:06 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 10 Jan 2019 12:17:06 -0500
Subject: GitLab forks and submodules
In-Reply-To: <CAMQQO3=PLg5_Oy5i31ccsyui+o7Hhh5wWLskYRUxg1Q364EQSg@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3=PLg5_Oy5i31ccsyui+o7Hhh5wWLskYRUxg1Q364EQSg@mail.gmail.com>
Message-ID: <875zuwl9f8.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

> &gt; while making the case of contributing patches with submodule changes more
> &gt; difficult
>
> I don't understand this, can you give an example of what absolute paths make
> harder?
>
> Looking at the wiki pages and scripts we need to make relative paths work for
> everyone, I think it's clear that absolute paths would be better because CI
> wouldn't need any scripts anymore and users would need no instructions to make
> cloning forks work.
>
The problem comes when a user needs to modify a submodule. In this case
then need the submodule to pull from their clone until their patch is
accepted upstream. There is no single submodule path scheme that works
in both this case and the (likely more common case) of a causual
contributor wanting to make a change to only the GHC repository.

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/20190110/d4d0b059/attachment.sig>

From ben at well-typed.com  Thu Jan 10 17:18:43 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 10 Jan 2019 12:18:43 -0500
Subject: GitLab forks and submodules
In-Reply-To: <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
Message-ID: <8736q0l9cf.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

>> As I mention in the documentation, those with commits bits should feel
>> free to push branches to ghc/ghc.
>
> This is sometimes not ideal as it wastes GHC's CI resources. For example I make
> a lot of WIP commits to my work branches, and I don't want to keep CI machines
> busy for those.
>
This is precisely why we have the two-phase CI configuration. It ensures
that obviously-wrong changes waste no more than two Linux builds worth of
effort. We currently have plenty of Linux capacity so I'm not terribly
worried about this.

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/20190110/ec3fcfcc/attachment.sig>

From ben at smart-cactus.org  Thu Jan 10 17:23:09 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 12:23:09 -0500
Subject: GitLab forks and submodules
In-Reply-To: <1C1BC502-7FE0-4900-9BD1-B4513B186161@gmail.com>
References: <B6B283D4-D6F9-4A56-8E9E-8860C4944413@gmail.com>
 <87lg3wmqk0.fsf@smart-cactus.org>
 <AM0PR83MB030894EA6F2D822B44E9CE41AD890@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87ftu4ma9p.fsf@smart-cactus.org>
 <010A181D-D3FC-47D3-9DFD-74C3979F0774@gmail.com>
 <87zhsblxue.fsf@smart-cactus.org>
 <CAMQQO3nPXV6N1+-q7cr90AxEy8QQxBR58YL3F2aaXQDsSEdtAg@mail.gmail.com>
 <CAK-hX0mTNJXQqkWkAagDnYDor1P1H6TSC7tsdzsuO+-BCjaG9A@mail.gmail.com>
 <CALuQ0m8bBj9N_vJzMpc1rx0E2eT2SvAEMGb0-Lt30U67vNn1Ag@mail.gmail.com>
 <CAHYVw0yVpPjHvkSa59=Z2EzQ2ak0FOM1EoeR96T8QM+g3jvCbw@mail.gmail.com>
 <1C1BC502-7FE0-4900-9BD1-B4513B186161@gmail.com>
Message-ID: <87zhs8jukl.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Alright let me add some example that is really painful with submodules.
>
> Say I have a custom ghc fork angerman/ghc, because I really don't want
> to overload CI with all my stupidity and I *know* I'd forget to mark
> every commit with [skip ci] or something.
>
> Now I need to modify a bunch of submodules as well, say
> - libraries/bytestring
> - libraires/unix
>
> And next I want to have someone else collaborate on this with me, either
> for testing or contributing or what not.
>
> So I'm going to give them the following commands to run:
>
> git clone --recursive https://gitlab.haskell.org/ghc/ghc
> (cd ghc && git remote add angerman https://gitlab.haskell.org/angerman/ghc)
> (cd ghc && git fetch --all)
> (cd ghc/libraries/bytestring && git remote add angerman https://github.com/angerman/bytestring && git fetch --all)
> (cd ghc/libraries/unix && git remote add angerman https://github.com/angerman/unix && git fetch --all)
> (cd ghc && git checkout angerman/awesome/sauce)
> (cd ghc && git submodule update --init --recursive)
>
If you pushed your bytestring and unix changes to your gitlab account
then this wouldn't be necessary. The fact that we use relative paths
would actually work to your advantage.

My current thinking is that the fix-submodules script run by CI should
do the following for each submodule:

 * If the branch has changed the submodule then do nothing (leaving the
   submodule URL as relative; this ensures that a user can push their
   submodule changes to their fork of the submodule on GitLab and things
   will "just work"

 * If the branch has not changed then rewrite the submodule URL to point
   to gitlab.haskell.org/ghc/packages/.... This ensures that CI will work
   for contributors making non-submodule changes in their GHC forks.

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/20190110/e9d08916/attachment.sig>

From ben at smart-cactus.org  Thu Jan 10 17:40:47 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 12:40:47 -0500
Subject: Reviews
In-Reply-To: <CACbaDy4FDz7=WnRc+AZmcN-wL__GkWkaUpLh=mE7xUS4bm=D6g@mail.gmail.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy4FDz7=WnRc+AZmcN-wL__GkWkaUpLh=mE7xUS4bm=D6g@mail.gmail.com>
Message-ID: <87sgy0jtrf.fsf@smart-cactus.org>

Evan Laforge <qdunkan at gmail.com> writes:

> On Tue, Jan 8, 2019 at 8:54 PM Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> |  > When submitting a review, I often want to add an overall comment, not
>> |  related to  a particular line of code?  How do I do that?
>> |
>> |  I do that by going back to the "Discussion" tab and adding something at the
>> |  bottom.
>>
>> But alas then it does not form part of the review, landing as a single email. It becomes a separate, disconnected comment.
>
> As far as I can tell, Gitlab doesn't really have a concept of a
> review, it's just big pile of disconnected comments... or rather,
> they're just all connected to the MR.


This isn't quite true. Transactional reviews were added in GitLab 11.4
[1]. That being said, the connection between the comments in a review is
a bit looser than it was in Phabricator.


Cheers,

- Ben

[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1984
-------------- 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/20190110/46d09525/attachment.sig>

From simonpj at microsoft.com  Thu Jan 10 17:42:18 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Jan 2019 17:42:18 +0000
Subject: Reviews
In-Reply-To: <87sgy0jtrf.fsf@smart-cactus.org>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy4FDz7=WnRc+AZmcN-wL__GkWkaUpLh=mE7xUS4bm=D6g@mail.gmail.com>
 <87sgy0jtrf.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB0308EF7133171CE5934A7749AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>

To return to the original question, how do I add an overall comment for a (multi-comment) review?

Simon

|  -----Original Message-----
|  From: Ben Gamari <ben at smart-cactus.org>
|  Sent: 10 January 2019 17:41
|  To: Evan Laforge <qdunkan at gmail.com>; Simon Peyton Jones
|  <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: Reviews
|  
|  Evan Laforge <qdunkan at gmail.com> writes:
|  
|  > On Tue, Jan 8, 2019 at 8:54 PM Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  >> |  > When submitting a review, I often want to add an overall
|  >> | comment, not  related to  a particular line of code?  How do I do
|  that?
|  >> |
|  >> |  I do that by going back to the "Discussion" tab and adding
|  >> | something at the  bottom.
|  >>
|  >> But alas then it does not form part of the review, landing as a single
|  email. It becomes a separate, disconnected comment.
|  >
|  > As far as I can tell, Gitlab doesn't really have a concept of a
|  > review, it's just big pile of disconnected comments... or rather,
|  > they're just all connected to the MR.
|  
|  
|  This isn't quite true. Transactional reviews were added in GitLab 11.4 [1].
|  That being said, the connection between the comments in a review is a bit
|  looser than it was in Phabricator.
|  
|  
|  Cheers,
|  
|  - Ben
|  
|  [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1984

From simonpj at microsoft.com  Thu Jan 10 17:44:16 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Jan 2019 17:44:16 +0000
Subject: More GitLab questions
In-Reply-To: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <AM0PR83MB0308AED333168AE1944DDEA9AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>

  *   If I respond to a comment (in review mode) but forget to check "resolved", it says "Discussion stays unresolved" correctly. But how do I now change it to "resolved"??

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Simon Peyton Jones via ghc-devs
Sent: 10 January 2019 17:16
To: ghc-devs <ghc-devs at haskell.org>
Subject: More GitLab questions


  *   When looking at a comment on a MR, I see some snippet of code.  How can I see what module that snippet is in?  Apart from scrolling up to find the file header - being careful not to miss it and scroll into the previous file.
  *   When looking a comment, there's a little button to skip to the next unresolved comment.  Good.  But if I respond to the comment (without resolving it), that little button disappears. How can I find the next unresolved comment?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190110/8a57a7e9/attachment.html>

From ben at smart-cactus.org  Thu Jan 10 17:45:41 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 12:45:41 -0500
Subject: Reviews
In-Reply-To: <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <8736q0jtj1.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> |  > When submitting a review, I often want to add an overall comment, not
> |  related to  a particular line of code?  How do I do that?
> |  
> |  I do that by going back to the "Discussion" tab and adding something at the
> |  bottom.
>
> But alas then it does not form part of the review, landing as a single
> email. It becomes a separate, disconnected comment.
>
Right, while code comments are transactional unfortunately "discussion"
comments are currently not. I'm not sure there are currently plans to
change this.

Another issue is that apparently GitLab still sends one email per
comment instead of one comment per batch. This will evidently be fixed
in GitLab 11.6 [1].

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/4326
-------------- 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/20190110/635b07a0/attachment.sig>

From simonpj at microsoft.com  Thu Jan 10 17:50:28 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Jan 2019 17:50:28 +0000
Subject: Reviews
In-Reply-To: <8736q0jtj1.fsf@smart-cactus.org>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  Another issue is that apparently GitLab still sends one email per comment
|  instead of one comment per batch. This will evidently be fixed in GitLab
|  11.6 [1].

yes that is TERRIBLE.  When does 11.6 land?

What I want is to have a batch of comments with an overview message.  We used that /all the time/ in Phab!  For example:

   I like this patch but you might want to think about X and Y.
   Meanwhile I have added a bunch of detailed comments.

This would fit very well with the "batch of comments in one email" change.

Simon

|  -----Original Message-----
|  From: Ben Gamari <ben at smart-cactus.org>
|  Sent: 10 January 2019 17:46
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Evan Laforge
|  <qdunkan at gmail.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: RE: Reviews
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
|  
|  > |  > When submitting a review, I often want to add an overall comment,
|  > | not  related to  a particular line of code?  How do I do that?
|  > |
|  > |  I do that by going back to the "Discussion" tab and adding
|  > | something at the  bottom.
|  >
|  > But alas then it does not form part of the review, landing as a single
|  > email. It becomes a separate, disconnected comment.
|  >
|  Right, while code comments are transactional unfortunately "discussion"
|  comments are currently not. I'm not sure there are currently plans to
|  change this.
|  
|  Another issue is that apparently GitLab still sends one email per comment
|  instead of one comment per batch. This will evidently be fixed in GitLab
|  11.6 [1].
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/4326

From ben at smart-cactus.org  Thu Jan 10 17:53:05 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 12:53:05 -0500
Subject: Reviews
In-Reply-To: <AM0PR83MB0308EF7133171CE5934A7749AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy4FDz7=WnRc+AZmcN-wL__GkWkaUpLh=mE7xUS4bm=D6g@mail.gmail.com>
 <87sgy0jtrf.fsf@smart-cactus.org>
 <AM0PR83MB0308EF7133171CE5934A7749AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87y37siem8.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> To return to the original question, how do I add an overall comment for a (multi-comment) review?
>
Unfortunately you can only add an overall comment separate from the
multi-comment review. I have inquired [1] about the status of this
feature with upstream.

Cheers,

- Ben

[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1984#note_130609989
-------------- 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/20190110/032128e5/attachment.sig>

From ben at smart-cactus.org  Thu Jan 10 18:18:39 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 13:18:39 -0500
Subject: More GitLab questions
In-Reply-To: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87va2widfo.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

>   * When looking at a comment on a MR, I see some snippet of code. How
>     can I see what module that snippet is in? Apart from scrolling up to
>     find the file header - being careful not to miss it and scroll into
>     the previous file.
>
Sigh, yes. This is an unfortunate lack in the UI that I have noticed as
well. I drew upstream's attention to it a while back and they indicated [1]
that they will be fixing this in the next 3-4 releases. I have raised a
signal with upstream indicating that this is causing us considerable
pain in hopes that they prioritize it [2].

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/53356
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039#note_130613037

>   * When looking a comment, there's a little button to skip to the
>     next unresolved comment. Good. But if I respond to the comment
>     (without resolving it), that little button disappears. How can I
>     find the next unresolved comment?

Hmm, that is strange. I can't reproduce this. I see the button remain at
the end of the discussion, even after I leave a comment [1]. Perhaps
this [2] is the issue you are seeing?

[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/97/diffs#note_2368
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/21689

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/20190110/10da5f24/attachment.sig>

From ben at smart-cactus.org  Thu Jan 10 18:27:09 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 10 Jan 2019 13:27:09 -0500
Subject: Reviews
In-Reply-To: <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87r2dkid1g.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  Another issue is that apparently GitLab still sends one email per comment
> |  instead of one comment per batch. This will evidently be fixed in GitLab
> |  11.6 [1].
>
> yes that is TERRIBLE.  When does 11.6 land?
>
It is the next release. I will poke our contact to make sure that they
realize the severity of the issue.

> What I want is to have a batch of comments with an overview message.
> We used that /all the time/ in Phab! For example:
>
>    I like this patch but you might want to think about X and Y.
>    Meanwhile I have added a bunch of detailed comments.
>
> This would fit very well with the "batch of comments in one email" change.
>
Indeed and upstream agrees. They created a feature request [1] in response
to my suggestion. I'll make sure that I mention this to our GitLab contact.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9145

-------------- 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/20190110/efb20d1d/attachment.sig>

From rae at cs.brynmawr.edu  Thu Jan 10 19:04:30 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 10 Jan 2019 14:04:30 -0500
Subject: Reviews
In-Reply-To: <87r2dkid1g.fsf@smart-cactus.org>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87r2dkid1g.fsf@smart-cactus.org>
Message-ID: <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>

While we're whinging:

- I'm looking at the Discussion page for an MR (https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904) and I see a comment Simon made, beginning with "No, I am not!". I wanted a bit more context. So I click on the filename above the Discussion and am warped to the Changes view (https://gitlab.haskell.org/ghc/ghc/merge_requests/74/diffs#9f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853 <https://gitlab.haskell.org/ghc/ghc/merge_requests/74/diffs#9f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853>). But Simon's comment isn't there. Instead, I see a different comment, beginning with "In canEqTyVar we now compare kinds...". So I'm lost here.

- Simon recently posted a bunch of comments in response to a bunch of my comments. I have a thick stack of emails about each individual comment. But when I view the discussion page (https://gitlab.haskell.org/ghc/ghc/merge_requests/74 <https://gitlab.haskell.org/ghc/ghc/merge_requests/74>), I can find Simon's comments only buried in the Discussions that I started. There appears to be no way to glean, from the web page, what has happened since last I looked. Is there a way to see a "log" of activity on an MR? That way, in case I'm drowning in email (common occurrence) and just want to get up to speed on a given MR, I can get an idea of what's gone on. Now, the thick stack of emails seems like the only way to do this.

- Is there a way to get a timestamped list of what discussions are resolved? Sometimes it's nice to be able to check that the resolution was what I had hoped for.

- The Changes page has a table of contents on the left. This is useful sometimes. (In this way, GL beats Phab, where it was sometimes hard to find where a certain file is listed when in the middle of a review.) But is there a way to collapse the ToC? Most of the time, I'm focused on the code itself, and the ToC drastically reduces the number of characters per line, when I view diffs side-by-side.

Thanks!
Richard

PS: I well remember how phrustrated I was with Phab when that rolled out, and how I eventually came to appreciate it. I'm being more patient this time around. In retrospect my trouble was more with arcanist than with Phab itself. (Arcanist and I never really got along... we just reached an unsteady truce, and I won't miss it.) I am happy to be using git as the tool now. But it's effortful to figure out efficient workflows in a new space, and I'm grateful for any help here. Thanks.

> On Jan 10, 2019, at 1:27 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Simon Peyton Jones <simonpj at microsoft.com> writes:
> 
>> |  Another issue is that apparently GitLab still sends one email per comment
>> |  instead of one comment per batch. This will evidently be fixed in GitLab
>> |  11.6 [1].
>> 
>> yes that is TERRIBLE.  When does 11.6 land?
>> 
> It is the next release. I will poke our contact to make sure that they
> realize the severity of the issue.
> 
>> What I want is to have a batch of comments with an overview message.
>> We used that /all the time/ in Phab! For example:
>> 
>>   I like this patch but you might want to think about X and Y.
>>   Meanwhile I have added a bunch of detailed comments.
>> 
>> This would fit very well with the "batch of comments in one email" change.
>> 
> Indeed and upstream agrees. They created a feature request [1] in response
> to my suggestion. I'll make sure that I mention this to our GitLab contact.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9145
> 
> _______________________________________________
> 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/20190110/4d328bb8/attachment.html>

From simonpj at microsoft.com  Fri Jan 11 09:49:26 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Jan 2019 09:49:26 +0000
Subject: Reviews
In-Reply-To: <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87r2dkid1g.fsf@smart-cactus.org>
 <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308A734E7D426622D84C90EAD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>

So I click on the filename above the Discussion and am warped to the Changes view (https://gitlab.haskell.org/ghc/ghc/merge_requests/74/diffs#9f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74%2Fdiffs%239f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744742026&sdata=eRJYkGGmP3rFPtxXGe3Lbe27YWeXnY9f1azHbtt0srw%3D&reserved=0>). But Simon's comment isn't there. Instead, I see a different comment, beginning with "In canEqTyVar we now compare kinds...". So I'm lost here.

When I try that, it starts by displaying the code from the file.  No rotating circles or anything. But if I wait ten seconds, suddenly the comments appear.   So:

  *   rendering seems terribly slow
  *   there is no indication that it is incomplete

Maybe you just weren't waiting long enough?

Even displaying the original MR https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904 is slow. For 18 seconds it displays a kind of skeleton page with horizontal grey bars that flash occasionally.  Then it renders.

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 10 January 2019 19:05
To: Ben Gamari <ben at smart-cactus.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Evan Laforge <qdunkan at gmail.com>; ghc-devs <ghc-devs at haskell.org>
Subject: Re: Reviews

While we're whinging:

- I'm looking at the Discussion page for an MR (https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74%23note_1904&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744742026&sdata=7l4qk3zTl4HuE0NvT2W8kWbIILmqXYZf0Wjj5KTq%2FzE%3D&reserved=0>) and I see a comment Simon made, beginning with "No, I am not!". I wanted a bit more context. So I click on the filename above the Discussion and am warped to the Changes view (https://gitlab.haskell.org/ghc/ghc/merge_requests/74/diffs#9f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74%2Fdiffs%239f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744742026&sdata=eRJYkGGmP3rFPtxXGe3Lbe27YWeXnY9f1azHbtt0srw%3D&reserved=0>). But Simon's comment isn't there. Instead, I see a different comment, beginning with "In canEqTyVar we now compare kinds...". So I'm lost here.

- Simon recently posted a bunch of comments in response to a bunch of my comments. I have a thick stack of emails about each individual comment. But when I view the discussion page (https://gitlab.haskell.org/ghc/ghc/merge_requests/74<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744752067&sdata=1OoWI%2FzgymMOnP8FI9AX%2Btv09ErmsQA%2FEmVK6gccHm4%3D&reserved=0>), I can find Simon's comments only buried in the Discussions that I started. There appears to be no way to glean, from the web page, what has happened since last I looked. Is there a way to see a "log" of activity on an MR? That way, in case I'm drowning in email (common occurrence) and just want to get up to speed on a given MR, I can get an idea of what's gone on. Now, the thick stack of emails seems like the only way to do this.

- Is there a way to get a timestamped list of what discussions are resolved? Sometimes it's nice to be able to check that the resolution was what I had hoped for.

- The Changes page has a table of contents on the left. This is useful sometimes. (In this way, GL beats Phab, where it was sometimes hard to find where a certain file is listed when in the middle of a review.) But is there a way to collapse the ToC? Most of the time, I'm focused on the code itself, and the ToC drastically reduces the number of characters per line, when I view diffs side-by-side.

Thanks!
Richard

PS: I well remember how phrustrated I was with Phab when that rolled out, and how I eventually came to appreciate it. I'm being more patient this time around. In retrospect my trouble was more with arcanist than with Phab itself. (Arcanist and I never really got along... we just reached an unsteady truce, and I won't miss it.) I am happy to be using git as the tool now. But it's effortful to figure out efficient workflows in a new space, and I'm grateful for any help here. Thanks.


On Jan 10, 2019, at 1:27 PM, Ben Gamari <ben at smart-cactus.org<mailto:ben at smart-cactus.org>> wrote:

Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> writes:


|  Another issue is that apparently GitLab still sends one email per comment
|  instead of one comment per batch. This will evidently be fixed in GitLab
|  11.6 [1].

yes that is TERRIBLE.  When does 11.6 land?
It is the next release. I will poke our contact to make sure that they
realize the severity of the issue.


What I want is to have a batch of comments with an overview message.
We used that /all the time/ in Phab! For example:

  I like this patch but you might want to think about X and Y.
  Meanwhile I have added a bunch of detailed comments.

This would fit very well with the "batch of comments in one email" change.
Indeed and upstream agrees. They created a feature request [1] in response
to my suggestion. I'll make sure that I mention this to our GitLab contact.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9145<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgitlab-org%2Fgitlab-ee%2Fissues%2F9145&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744762041&sdata=hX4fjwdMRWF%2FnJew5St6WkB9lb77LmRxgUvvesbXy5k%3D&reserved=0>

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190111/83dc99b6/attachment-0001.html>

From simonpj at microsoft.com  Fri Jan 11 09:53:40 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Jan 2019 09:53:40 +0000
Subject: Reviews
In-Reply-To: <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87r2dkid1g.fsf@smart-cactus.org>
 <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
Message-ID: <AM0PR83MB03088713D6378640527FB36CAD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Is there a way to see a "log" of activity on an MR? That way, in case I'm drowning in email (common occurrence) and just want to get up to speed on a given MR, I can get an idea of what's gone on.

What I expected was:


  *   The Discussion tab shows a time-sequenced log of activity
  *   The Changes tab shows topic-focused threads of discussion, each thread starting at a line of code.

(This is more or less what Phab did.)

But actually the Discussion tab seems to be no more than a concatenation of the threads in the Changes tab, so as Richard says there is no way to see the recent changes.

How sad!

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 10 January 2019 19:05
To: Ben Gamari <ben at smart-cactus.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Evan Laforge <qdunkan at gmail.com>; ghc-devs <ghc-devs at haskell.org>
Subject: Re: Reviews

While we're whinging:

- I'm looking at the Discussion page for an MR (https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74%23note_1904&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744742026&sdata=7l4qk3zTl4HuE0NvT2W8kWbIILmqXYZf0Wjj5KTq%2FzE%3D&reserved=0>) and I see a comment Simon made, beginning with "No, I am not!". I wanted a bit more context. So I click on the filename above the Discussion and am warped to the Changes view (https://gitlab.haskell.org/ghc/ghc/merge_requests/74/diffs#9f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74%2Fdiffs%239f8e9eab0dc8b12ae9f92fbb76ddca15c817667a_1852_1853&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744742026&sdata=eRJYkGGmP3rFPtxXGe3Lbe27YWeXnY9f1azHbtt0srw%3D&reserved=0>). But Simon's comment isn't there. Instead, I see a different comment, beginning with "In canEqTyVar we now compare kinds...". So I'm lost here.

- Simon recently posted a bunch of comments in response to a bunch of my comments. I have a thick stack of emails about each individual comment. But when I view the discussion page (https://gitlab.haskell.org/ghc/ghc/merge_requests/74<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F74&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744752067&sdata=1OoWI%2FzgymMOnP8FI9AX%2Btv09ErmsQA%2FEmVK6gccHm4%3D&reserved=0>), I can find Simon's comments only buried in the Discussions that I started. There appears to be no way to glean, from the web page, what has happened since last I looked. Is there a way to see a "log" of activity on an MR? That way, in case I'm drowning in email (common occurrence) and just want to get up to speed on a given MR, I can get an idea of what's gone on. Now, the thick stack of emails seems like the only way to do this.

- Is there a way to get a timestamped list of what discussions are resolved? Sometimes it's nice to be able to check that the resolution was what I had hoped for.

- The Changes page has a table of contents on the left. This is useful sometimes. (In this way, GL beats Phab, where it was sometimes hard to find where a certain file is listed when in the middle of a review.) But is there a way to collapse the ToC? Most of the time, I'm focused on the code itself, and the ToC drastically reduces the number of characters per line, when I view diffs side-by-side.

Thanks!
Richard

PS: I well remember how phrustrated I was with Phab when that rolled out, and how I eventually came to appreciate it. I'm being more patient this time around. In retrospect my trouble was more with arcanist than with Phab itself. (Arcanist and I never really got along... we just reached an unsteady truce, and I won't miss it.) I am happy to be using git as the tool now. But it's effortful to figure out efficient workflows in a new space, and I'm grateful for any help here. Thanks.


On Jan 10, 2019, at 1:27 PM, Ben Gamari <ben at smart-cactus.org<mailto:ben at smart-cactus.org>> wrote:

Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> writes:


|  Another issue is that apparently GitLab still sends one email per comment
|  instead of one comment per batch. This will evidently be fixed in GitLab
|  11.6 [1].

yes that is TERRIBLE.  When does 11.6 land?
It is the next release. I will poke our contact to make sure that they
realize the severity of the issue.


What I want is to have a batch of comments with an overview message.
We used that /all the time/ in Phab! For example:

  I like this patch but you might want to think about X and Y.
  Meanwhile I have added a bunch of detailed comments.

This would fit very well with the "batch of comments in one email" change.
Indeed and upstream agrees. They created a feature request [1] in response
to my suggestion. I'll make sure that I mention this to our GitLab contact.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9145<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgitlab-org%2Fgitlab-ee%2Fissues%2F9145&data=02%7C01%7Csimonpj%40microsoft.com%7C728cbed6e44946c21bae08d6772e7477%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636827438744762041&sdata=hX4fjwdMRWF%2FnJew5St6WkB9lb77LmRxgUvvesbXy5k%3D&reserved=0>

_______________________________________________
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

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

From simonpj at microsoft.com  Fri Jan 11 10:16:18 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Jan 2019 10:16:18 +0000
Subject: More GitLab questions
In-Reply-To: <87va2widfo.fsf@smart-cactus.org>
References: <AM0PR83MB0308DB12D993D3A398BE7402AD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87va2widfo.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB03086D918739909FF0B74718AD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  >   * When looking a comment, there's a little button to skip to the
|  >     next unresolved comment. Good. But if I respond to the comment
|  >     (without resolving it), that little button disappears. How can I
|  >     find the next unresolved comment?
|  
|  Hmm, that is strange. I can't reproduce this. 

Aha!  The bad behaviour only happens when you are in "review mode".

If you add a comment with "Add comment now", then you are given buttons to
* Resolve or un-resolve the discussion
* Move to the next unresolved point

But if you add a comment with "Start a review" (or "add to review"), then those affordances disappear entirely.

That's my problem.

Simon


From rae at cs.brynmawr.edu  Fri Jan 11 16:04:55 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 11 Jan 2019 11:04:55 -0500
Subject: Reviews
In-Reply-To: <AM0PR83MB0308A734E7D426622D84C90EAD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87r2dkid1g.fsf@smart-cactus.org>
 <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
 <AM0PR83MB0308A734E7D426622D84C90EAD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <DBD02ACE-8B5C-4ABD-83AD-1C1C1F46E9F1@cs.brynmawr.edu>



> On Jan 11, 2019, at 4:49 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> When I try that, it starts by displaying the code from the file.  No rotating circles or anything. But if I wait ten seconds, suddenly the comments appear.   So:
> rendering seems terribly slow
> there is no indication that it is incomplete
>  
> Maybe you just weren’t waiting long enough?

I had a similar experience (with comments coming later, and with no indication that I should wait), but then the comments were incomplete when they did appear, including only your new comment, not the older one.

Richard

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

From carter.schonwald at gmail.com  Sat Jan 12 00:38:39 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 11 Jan 2019 19:38:39 -0500
Subject: Reviews
In-Reply-To: <DBD02ACE-8B5C-4ABD-83AD-1C1C1F46E9F1@cs.brynmawr.edu>
References: <AM0PR83MB0308DF8A85F0DCBD3B8CA3E3AD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CACbaDy7eu=Ej36OEcU=cHrXB8AiD11DVP3ofTHUMS3sSmFf64Q@mail.gmail.com>
 <AM0PR83MB030893418D9CD1A49E497C7BAD8A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736q0jtj1.fsf@smart-cactus.org>
 <AM0PR83MB0308E2443B47DF80606721CDAD840@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87r2dkid1g.fsf@smart-cactus.org>
 <9A448958-C3D8-47E6-94C7-43E178F742E1@cs.brynmawr.edu>
 <AM0PR83MB0308A734E7D426622D84C90EAD850@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <DBD02ACE-8B5C-4ABD-83AD-1C1C1F46E9F1@cs.brynmawr.edu>
Message-ID: <CAHYVw0wC5C5K3vDmGx-G=U8WPCsUfi6ZT8F0op7ZeTpT37OoAw@mail.gmail.com>

A similar issue happens in terms of rendering time if you look at a giant
change set, the caching seems pretty minimal on a lot of the rendering
steps in gitlab.

On Fri, Jan 11, 2019 at 11:05 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

>
>
> On Jan 11, 2019, at 4:49 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> When I try that, it starts by displaying the code from the file.  No
> rotating circles or anything. But if I wait ten seconds, suddenly the
> comments appear.   So:
>
>    - rendering seems terribly slow
>    - there is no indication that it is incomplete
>
>
> Maybe you just weren’t waiting long enough?
>
>
> I had a similar experience (with comments coming later, and with no
> indication that I should wait), but then the comments were incomplete when
> they did appear, including only your new comment, not the older one.
>
> Richard
>
> _______________________________________________
> 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/20190111/6e43382c/attachment.html>

From simonpj at microsoft.com  Mon Jan 14 09:28:28 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Jan 2019 09:28:28 +0000
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <note_2524@gitlab.haskell.org>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
Message-ID: <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Devs

I’m at a loss for how to review GitLab changes.  Richard sent me the message below.  So I follow the link to “View on GitLab”, or I manually edit the URL to plain
https://gitlab.haskell.org/ghc/ghc/merge_requests/116

Either way, I can’t see any comments whatsoever!  It says 5/5 discussions resolved, but I can’t actually see them.  There is not “toggle discussion” button anywhere.

What should I do?  This is quite a big problem.

I suppose we could issue guidance NEVER to resolve a discussion, but that seems like the wrong conclusion.

Simon

From: Richard Eisenberg <gitlab at gitlab.haskell.org>
Sent: 14 January 2019 03:03
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: GHC | Some refactoring in tcInferApps (!116)


Richard Eisenberg<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Frae&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb561c2c415642e1b95808d679cccdca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830317886025072&sdata=Tx8acLx5EqMZwPI5HaGByevMrszvpZMS0pk2S1YvHGg%3D&reserved=0> commented on a discussion on compiler/typecheck/TcHsType.hs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F116%23note_2524&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb561c2c415642e1b95808d679cccdca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830317886025072&sdata=axuADDuUAzYZkIDkS1Rnlt9Up13CbVG%2FKUgQYf4C38g%3D&reserved=0>:

1022


+                                 (vcat [ ppr ki_binder


1023


+                                       , ppr ki_arg


1024


+                                       , ppr (tyBinderType ki_binder)


1025


+                                       , ppr subst


1026


+                                       , ppr (isInvisibleBinder ki_binder) ])


1027


+                       ; ty_app_err ki_arg $ nakedSubstTy subst $


1028


+                                             mkPiTys all_ki_binders inner_ki }


1029


+


1030


+        -- no binder; try applying the substitution, or fail if that's not possible


1031


+      | otherwise


1032


+      = try_again_after_substing_or n subst fun inner_ki all_args $ \ substed_inner_ki ->


1033


+        ty_app_err ki_arg substed_inner_ki


1034


+


1035


+    go n subst fun all_ki_binders inner_ki all_args@(HsValArg arg : args)


1036


+      | ki_binder : ki_binders <- all_ki_binders


1037


+      = if isInvisibleBinder ki_binder


See if you like how I've done this now.

—
View it on GitLab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F116%23note_2524&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb561c2c415642e1b95808d679cccdca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830317886035081&sdata=M4jE8Z%2F0znjU9m7U2xMoPdytqCw6w4WAoVtAjjmC4%2BM%3D&reserved=0>.
You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fsent_notifications%2F5489179cb3c2c8e4eb34f7a8abd8016e%2Funsubscribe&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb561c2c415642e1b95808d679cccdca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830317886045089&sdata=dvqIZ%2BabXOGv8nX2uMse3dl1XlyEvsxyVKIxPLRvG%2BE%3D&reserved=0> from this thread or adjust your notification settings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e1d98228/attachment.html>

From mikolaj at well-typed.com  Mon Jan 14 09:46:11 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 14 Jan 2019 10:46:11 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org>
 <note_2520@gitlab.haskell.org> <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>

> Either way, I can’t see any comments whatsoever!  It says 5/5 discussions resolved, but I can’t actually see them.  There is not “toggle discussion” button anywhere.

Hello Simon,

Just below "5/5 discussions resolved" I can see 5 discussions
with “toggle discussion” link to the right of each one.
Is that what you can't see, or do mean a single button
that toggles all resolved discussions (I can't see any)?
Or do you mean a button that un-resolves them permanently
(neither can I see one)?

From simonpj at microsoft.com  Mon Jan 14 10:01:02 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Jan 2019 10:01:02 +0000
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
Message-ID: <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Looking here
https://gitlab.haskell.org/ghc/ghc/merge_requests/116//diffs
I see literally NO discussions with a "toggle discussion" button.  Indeed if I search for "toggle" I get no hits.

When I initially clicked on "changes", the diff for TcHsType was initially collapsed; I had to click on "Click to expand it".

I can't account for why the behaviour is different for you.

Simon

|  -----Original Message-----
|  From: Mikolaj Konarski <mikolaj at well-typed.com>
|  Sent: 14 January 2019 09:46
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: GHC | Some refactoring in tcInferApps (!116)
|  
|  > Either way, I can’t see any comments whatsoever!  It says 5/5 discussions
|  resolved, but I can’t actually see them.  There is not “toggle discussion”
|  button anywhere.
|  
|  Hello Simon,
|  
|  Just below "5/5 discussions resolved" I can see 5 discussions with “toggle
|  discussion” link to the right of each one.
|  Is that what you can't see, or do mean a single button that toggles all
|  resolved discussions (I can't see any)?
|  Or do you mean a button that un-resolves them permanently (neither can I
|  see one)?

From mikolaj at well-typed.com  Mon Jan 14 10:29:52 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 14 Jan 2019 11:29:52 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org>
 <note_2520@gitlab.haskell.org> <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>

> Looking here
> https://gitlab.haskell.org/ghc/ghc/merge_requests/116//diffs
> I see literally NO discussions with a "toggle discussion" button.  Indeed if I search for "toggle" I get no hits.

Oh, I see, you are right with respect to the link you cited now.
None of the buttons help, just as you say. I have
to navigate back from the "Changes" to the "Discussion" tab,
which gets me to the link you gave initially
(https://gitlab.haskell.org/ghc/ghc/merge_requests/116)
where the discussions are available, but I can't see them
in the context of the whole diff and none of the buttons
there let me extend the view of the diff. That's quite suboptimal.

Could you confirm that at

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

(without the 'diff' at the end) you can see the collapsed discussion items?

From simonpj at microsoft.com  Mon Jan 14 10:58:07 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Jan 2019 10:58:07 +0000
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
Message-ID: <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  (without the 'diff' at the end) you can see the collapsed discussion items?

Yes, in the discussion tab I can.  But of course that is out of context; you just get a little (non-expandable) snippet.

Simon

|  -----Original Message-----
|  From: Mikolaj Konarski <mikolaj at well-typed.com>
|  Sent: 14 January 2019 10:30
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: GHC | Some refactoring in tcInferApps (!116)
|  
|  > Looking here
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F116%2F%2Fdiffs&amp;data=
|  > 02%7C01%7Csimonpj%40microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7
|  > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830586093208883&amp;sda
|  > ta=qAcz0zoXCCQHFeJ39ABKAVwtN5a2pIwyRSbfJcLSurk%3D&amp;reserved=0
|  > I see literally NO discussions with a "toggle discussion" button.  Indeed
|  if I search for "toggle" I get no hits.
|  
|  Oh, I see, you are right with respect to the link you cited now.
|  None of the buttons help, just as you say. I have to navigate back from the
|  "Changes" to the "Discussion" tab, which gets me to the link you gave
|  initially
|  (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40
|  microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7c
|  d011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm
|  4ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0)
|  where the discussions are available, but I can't see them in the context of
|  the whole diff and none of the buttons there let me extend the view of the
|  diff. That's quite suboptimal.
|  
|  Could you confirm that at
|  
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
|  skell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40m
|  icrosoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7cd
|  011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm4
|  ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0
|  
|  (without the 'diff' at the end) you can see the collapsed discussion items?

From mikolaj at well-typed.com  Mon Jan 14 11:46:41 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 14 Jan 2019 12:46:41 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org>
 <note_2520@gitlab.haskell.org> <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
 <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHFo2uq-B3ic0pkEEMRgwP01Mt5h9vSC+oiKniF3KUc8FaNeyg@mail.gmail.com>

> Yes, in the discussion tab I can.  But of course that is out of context; you just get a little (non-expandable) snippet.

I lack the gitlab experience to push this any further, but I guess
an "unresolve discussion" button/checkbox would at least be
a stop-gap measure. I couldn't see such a button on the page,
probably because I don't have the required permissions for this MR.
However, the video in the ticket below (and lots of noise
elsewhere on the net) suggests such a button might exists.
Ben, or anybody, do you know anything more about that?

https://gitlab.com/gitlab-org/gitlab-ce/issues/53930

From mikolaj at well-typed.com  Mon Jan 14 12:30:52 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 14 Jan 2019 13:30:52 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org>
 <note_2520@gitlab.haskell.org> <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHFo2upjr5=X-nbq4Dz++ma4A-jeLQEoc=i7ztgNAtmpp0_xoQ@mail.gmail.com>

On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:
>
> I suppose we could issue guidance NEVER to resolve a discussion, but that
seems like the wrong conclusion.

It seems gitlab's "resolve discussion" action is supposed to mean
"I think nobody needs to look at these comments (in detail) any more".

So if somebody addressed your comment, he should probably
ping you with "this comment addressed", then you look at the comment,
at the old diff, at the new diff (no idea how easy it is to switch between
the old and new diffs) and then *you* resolve the discussion, if satisfied.
And if somebody resolves discussion prematurely, you unresolve it
with the button or checkbox, meaning "actually, I'd like to have
one more close look before the discussion is hidden forever".
You can even add an unresolve comment explaining why you think
the additional look is needed after all.

All this is quite troublesome if there is a lot of comments
and they need to be pinged about, resolved and unresolved
in bulk (unless I'm missing some bulk button).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/50e7655d/attachment.html>

From rae at cs.brynmawr.edu  Mon Jan 14 13:41:46 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 14 Jan 2019 08:41:46 -0500
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <CAHFo2upjr5=X-nbq4Dz++ma4A-jeLQEoc=i7ztgNAtmpp0_xoQ@mail.gmail.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2upjr5=X-nbq4Dz++ma4A-jeLQEoc=i7ztgNAtmpp0_xoQ@mail.gmail.com>
Message-ID: <0F42C4CE-909F-4B23-A3A5-D74AB682E2E7@cs.brynmawr.edu>

I confirm that I see "Unresolve discussion" buttons in the "Discussion" page, after "Toggle Discussion" is clicked.

Perhaps we have this working convention: the dev that starts the discussion is expected to resolve it. I doubt GL can enforce that convention, but we can just agree to it all. So, in the case at hand, I wrote the patch, and Simon started several discussions. As I address them, instead of resolving the discussions (as I did), I would just say "Done" (or similar). Then, Simon's re-review would spot my comments and then click resolve, when the matter has met his satisfaction.

Ben: I imagine this will not be the only such convention we arrive at in this vein. Is it possible (and reasonably easy) to set up some service whereby new contributors get a "welcome" email upon their first submission of an MR? (But only upon the *first* submission!) This would include hearty thanks for contributing, etc., but also a few GL pointers and our working conventions. To be honest, even forgetting about working conventions, an email of thanks at that stage would probably set the stage for a nice working environment for contributors. (Right now, they probably submit, get some silence, then see a slew of comments telling them what they've done wrong, and then get a "Thanks so much!" after all those negative comments. This may be somewhat standard in open-source -- and isn't so bad that it *needs* change -- but that doesn't mean we can't do better.)

Richard

> On Jan 14, 2019, at 7:30 AM, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
> 
> On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>> wrote:
> >
> > I suppose we could issue guidance NEVER to resolve a discussion, but that seems like the wrong conclusion.
> 
> It seems gitlab's "resolve discussion" action is supposed to mean
> "I think nobody needs to look at these comments (in detail) any more".
> 
> So if somebody addressed your comment, he should probably
> ping you with "this comment addressed", then you look at the comment,
> at the old diff, at the new diff (no idea how easy it is to switch between
> the old and new diffs) and then *you* resolve the discussion, if satisfied.
> And if somebody resolves discussion prematurely, you unresolve it
> with the button or checkbox, meaning "actually, I'd like to have
> one more close look before the discussion is hidden forever".
> You can even add an unresolve comment explaining why you think
> the additional look is needed after all.
> 
> All this is quite troublesome if there is a lot of comments
> and they need to be pinged about, resolved and unresolved
> in bulk (unless I'm missing some bulk button).
> 
> _______________________________________________
> 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/20190114/8221eedf/attachment.html>

From sylvain at haskus.fr  Mon Jan 14 16:20:37 2019
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 14 Jan 2019 17:20:37 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
 <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <e8f9c166-bb94-10fa-7927-d7aba1c0eebc@haskus.fr>

Hi Simon,

In the diff view, you can click on the avatars on the left to expand 
discussions:

Or you can click on the "toggle comments for this file" button:



If you are willing to use GreaseMonkey (Firefox extension) or 
TamperMonkey (Chrome/Chromium extension), you can use the attached 
script to add new buttons to GitLab UI:


Tested on Firefox and Chromium on Linux.

Sylvain




On 14/01/2019 11:58, Simon Peyton Jones via ghc-devs wrote:
> |  (without the 'diff' at the end) you can see the collapsed discussion items?
>
> Yes, in the discussion tab I can.  But of course that is out of context; you just get a little (non-expandable) snippet.
>
> Simon
>
> |  -----Original Message-----
> |  From: Mikolaj Konarski <mikolaj at well-typed.com>
> |  Sent: 14 January 2019 10:30
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Re: GHC | Some refactoring in tcInferApps (!116)
> |
> |  > Looking here
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F116%2F%2Fdiffs&amp;data=
> |  > 02%7C01%7Csimonpj%40microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7
> |  > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830586093208883&amp;sda
> |  > ta=qAcz0zoXCCQHFeJ39ABKAVwtN5a2pIwyRSbfJcLSurk%3D&amp;reserved=0
> |  > I see literally NO discussions with a "toggle discussion" button.  Indeed
> |  if I search for "toggle" I get no hits.
> |
> |  Oh, I see, you are right with respect to the link you cited now.
> |  None of the buttons help, just as you say. I have to navigate back from the
> |  "Changes" to the "Discussion" tab, which gets me to the link you gave
> |  initially
> |  (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40
> |  microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7c
> |  d011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm
> |  4ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0)
> |  where the discussions are available, but I can't see them in the context of
> |  the whole diff and none of the buttons there let me extend the view of the
> |  diff. That's quite suboptimal.
> |
> |  Could you confirm that at
> |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
> |  skell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40m
> |  icrosoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7cd
> |  011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm4
> |  ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0
> |
> |  (without the 'diff' at the end) you can see the collapsed discussion items?
> _______________________________________________
> 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/20190114/e56fcb05/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot-20190114 at 161655.png
Type: image/png
Size: 2641 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e56fcb05/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot-20190114 at 161824.png
Type: image/png
Size: 5791 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e56fcb05/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot-20190114 at 171150.png
Type: image/png
Size: 12613 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e56fcb05/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot-20190114 at 171141.png
Type: image/png
Size: 11851 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e56fcb05/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gitlab_ghc.user.js
Type: application/x-javascript
Size: 1000 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/e56fcb05/attachment.js>

From simonpj at microsoft.com  Mon Jan 14 17:11:21 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Jan 2019 17:11:21 +0000
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <a40a9d17-c8d1-46c6-b81f-194f1b881c22@CY4PR21MB0792.namprd21.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
 <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <a40a9d17-c8d1-46c6-b81f-194f1b881c22@CY4PR21MB0792.namprd21.prod.outlook.com>
Message-ID: <AM0PR83MB03085093166E76ADB44F2A9BAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Thanks.  But none of the pictures arrived, so I can’t interpret what you say.

I think I did see Richards face here and there (and mine), if that’s want avatars means. Hovering showed a snippet of a comment; but clicking did nothing.

I’m also terribly reluctant to scroll through thousands of lines of diff looking for avarars.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sylvain Henry
Sent: 14 January 2019 16:21
To: ghc-devs at haskell.org
Subject: Re: GHC | Some refactoring in tcInferApps (!116)


Hi Simon,

In the diff view, you can click on the avatars on the left to expand discussions:

[cid:part1.E17582DB.274298F8 at haskus.fr]

Or you can click on the "toggle comments for this file" button:

[cid:part2.D9953BB2.A74D4E27 at haskus.fr]





If you are willing to use GreaseMonkey (Firefox extension) or TamperMonkey (Chrome/Chromium extension), you can use the attached script to add new buttons to GitLab UI:

[cid:part3.9CF91D30.FC1AF3DA at haskus.fr]

[cid:part4.5144A0AF.98359F8A at haskus.fr]



Tested on Firefox and Chromium on Linux.

Sylvain





On 14/01/2019 11:58, Simon Peyton Jones via ghc-devs wrote:

|  (without the 'diff' at the end) you can see the collapsed discussion items?



Yes, in the discussion tab I can.  But of course that is out of context; you just get a little (non-expandable) snippet.



Simon



|  -----Original Message-----

|  From: Mikolaj Konarski <mikolaj at well-typed.com><mailto:mikolaj at well-typed.com>

|  Sent: 14 January 2019 10:30

|  To: Simon Peyton Jones <simonpj at microsoft.com><mailto:simonpj at microsoft.com>

|  Cc: ghc-devs <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>

|  Subject: Re: GHC | Some refactoring in tcInferApps (!116)

|

|  > Looking here

|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl

|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F116%2F%2Fdiffs&amp;data=

|  > 02%7C01%7Csimonpj%40microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7

|  > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830586093208883&amp;sda

|  > ta=qAcz0zoXCCQHFeJ39ABKAVwtN5a2pIwyRSbfJcLSurk%3D&amp;reserved=0

|  > I see literally NO discussions with a "toggle discussion" button.  Indeed

|  if I search for "toggle" I get no hits.

|

|  Oh, I see, you are right with respect to the link you cited now.

|  None of the buttons help, just as you say. I have to navigate back from the

|  "Changes" to the "Discussion" tab, which gets me to the link you gave

|  initially

|  (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h

|  askell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40

|  microsoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7c

|  d011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm

|  4ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0)

|  where the discussions are available, but I can't see them in the context of

|  the whole diff and none of the buttons there let me extend the view of the

|  diff. That's quite suboptimal.

|

|  Could you confirm that at

|

|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha

|  skell.org%2Fghc%2Fghc%2Fmerge_requests%2F116&amp;data=02%7C01%7Csimonpj%40m

|  icrosoft.com%7Cb565eeb2f6fe445fc64f08d67a0b40fe%7C72f988bf86f141af91ab2d7cd

|  011db47%7C1%7C0%7C636830586093208883&amp;sdata=1pFmcwPyptWE8XOs%2FdnykEqsm4

|  ag7%2BqBi3c4qpAE7sE%3D&amp;reserved=0

|

|  (without the 'diff' at the end) you can see the collapsed discussion items?

_______________________________________________

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%7C93db6e03da4842eeb08c08d67a3c434c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636830796575788410&sdata=NbKU6m%2BsIuL4XGKQdOOa5Q%2FTOMYGqa1q8e1lJ3Wyk%2F0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190114/6ff08c76/attachment.html>

From mikolaj at well-typed.com  Mon Jan 14 17:29:11 2019
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 14 Jan 2019 18:29:11 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB03085093166E76ADB44F2A9BAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org>
 <note_2520@gitlab.haskell.org> <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
 <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <a40a9d17-c8d1-46c6-b81f-194f1b881c22@CY4PR21MB0792.namprd21.prod.outlook.com>
 <AM0PR83MB03085093166E76ADB44F2A9BAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAHFo2upZbJQe9MDX15Ppw_-fVd+4G1eYjZSZGbC8FpdZDLEunA@mail.gmail.com>

Richard, what you propose totally makes sense to me.

Simon, Sylvain, indeed, when I click "toggle comments for this file"
in the first patch, I can see not only an avatar, but the whole comment.
However, this is only one comment, in both diffs, out of many,
which adds to the confusion. May it be caused by new changes
invalidating old comments? That's an orthogonal issue, which I remember
being quite annoying on github.

Also, with "toggle comments for this file" unmarked (it's really hard to tell
what the state of that button is), I can see the tiny avatar and, for me,
just clicking on it reveals the full comment.

From chrisdone at gmail.com  Tue Jan 15 00:23:17 2019
From: chrisdone at gmail.com (Christopher Done)
Date: Tue, 15 Jan 2019 00:23:17 +0000
Subject: Max identifier length
Message-ID: <CAAJHNPDcoSxSYm6OaAFMiqdLxNfCrN8kKdV+6jxSR5LqW6JZWA@mail.gmail.com>

Hey,

Quick question: Does GHC have an upper limit on the length of binding names?

Cheers!

From carter.schonwald at gmail.com  Tue Jan 15 02:48:35 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 14 Jan 2019 21:48:35 -0500
Subject: Max identifier length
In-Reply-To: <CAAJHNPDcoSxSYm6OaAFMiqdLxNfCrN8kKdV+6jxSR5LqW6JZWA@mail.gmail.com>
References: <CAAJHNPDcoSxSYm6OaAFMiqdLxNfCrN8kKdV+6jxSR5LqW6JZWA@mail.gmail.com>
Message-ID: <CAHYVw0z+vnxY7qnXsoKnjHjSLUcUuCc8eHNr881hH+1oH5xwHQ@mail.gmail.com>

definitely you'd have a bad day if you used up the heap :)

On Mon, Jan 14, 2019 at 7:23 PM Christopher Done <chrisdone at gmail.com>
wrote:

> Hey,
>
> Quick question: Does GHC have an upper limit on the length of binding
> names?
>
> Cheers!
> _______________________________________________
> 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/20190114/4df0a64e/attachment-0001.html>

From ben at smart-cactus.org  Tue Jan 15 02:56:01 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 14 Jan 2019 21:56:01 -0500
Subject: Max identifier length
In-Reply-To: <CAAJHNPDcoSxSYm6OaAFMiqdLxNfCrN8kKdV+6jxSR5LqW6JZWA@mail.gmail.com>
References: <CAAJHNPDcoSxSYm6OaAFMiqdLxNfCrN8kKdV+6jxSR5LqW6JZWA@mail.gmail.com>
Message-ID: <877ef6iq84.fsf@smart-cactus.org>

Christopher Done <chrisdone at gmail.com> writes:

> Hey,
>
> Quick question: Does GHC have an upper limit on the length of binding names?
>
IIRC parser does not impose such a limit.

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/20190114/66797601/attachment.sig>

From sylvain at haskus.fr  Tue Jan 15 13:18:55 2019
From: sylvain at haskus.fr (Sylvain Henry)
Date: Tue, 15 Jan 2019 14:18:55 +0100
Subject: GHC | Some refactoring in tcInferApps (!116)
In-Reply-To: <AM0PR83MB03085093166E76ADB44F2A9BAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <merge_request_130@gitlab.haskell.org>
 <note_2461@gitlab.haskell.org> <note_2520@gitlab.haskell.org>
 <note_2524@gitlab.haskell.org>
 <AM0PR83MB03082AC9F40F9FDDA58F9472AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uriSBq+Hj15SqpWnMp3qTrb36ox1u6KTbd1KrGS3wKrbQ@mail.gmail.com>
 <AM0PR83MB030815E1540CEDEEEF56FE2EAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAHFo2uoD=MHxwOaXfYyBW=KaUWbH5MAmHfeUmavvOmy5s70Hnw@mail.gmail.com>
 <AM0PR83MB0308A7CEE656C179CAB1F7A5AD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <a40a9d17-c8d1-46c6-b81f-194f1b881c22@CY4PR21MB0792.namprd21.prod.outlook.com>
 <AM0PR83MB03085093166E76ADB44F2A9BAD800@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <a3952aa0-cfed-a11e-7deb-b09bb8acac40@haskus.fr>

 > Thanks.  But none of the pictures arrived, so I can’t interpret what 
you say.

They probably have been filtered by the ML...

They can seen with the script here: 
https://gist.github.com/hsyl20/912b0a5fec9e7c621d8ac82e46b88d93



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

From omeragacan at gmail.com  Wed Jan 16 07:01:10 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 16 Jan 2019 10:01:10 +0300
Subject: Bug in "changes" tab in Gitlab
Message-ID: <CAMQQO3=eAm-ASBMC+ctpfPjPZAK3VG3WK-Ea0yEtNJ7xTbM9jA@mail.gmail.com>

Hi,

I think there's a currently a bug in "changes" tab in gitlab. If you look at [1]
it shows as if I added a new line in `Main.hs`, but actually I just changed one
word:

    diff --git a/utils/genapply/Main.hs b/utils/genapply/Main.hs
    index 71b84fde79..7038dc5c09 100644
    --- a/utils/genapply/Main.hs
    +++ b/utils/genapply/Main.hs
    @@ -903,7 +903,7 @@ genStackApply regstatus args =
     --
     -- These code fragments are used to save registers on the stack at a heap
     -- check failure in the entry code for a function.  We also have to save R1
    --- and the return address (stg_gc_fun_info) on the stack.  See
stg_gc_fun_gen
    +-- and the return address (stg_gc_fun_info) on the stack.  See __stg_gc_fun
     -- in HeapStackCheck.cmm for more details.

I'm guessing that Gitlab is confused by the `---` prefix in the diff.

I was going to report it but I realized that we're not using the latest version
(the "help" page says "update asap"), so perhaps we should try updating first?

[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/125/diffs?view=parallel

Ömer

From ben at smart-cactus.org  Wed Jan 16 14:28:28 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 16 Jan 2019 09:28:28 -0500
Subject: Bug in "changes" tab in Gitlab
In-Reply-To: <CAMQQO3=eAm-ASBMC+ctpfPjPZAK3VG3WK-Ea0yEtNJ7xTbM9jA@mail.gmail.com>
References: <CAMQQO3=eAm-ASBMC+ctpfPjPZAK3VG3WK-Ea0yEtNJ7xTbM9jA@mail.gmail.com>
Message-ID: <87won4he2g.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

> Hi,
>
> I think there's a currently a bug in "changes" tab in gitlab. If you
> look at [1] it shows as if I added a new line in `Main.hs`, but
> actually I just changed one word:
>
>     diff --git a/utils/genapply/Main.hs b/utils/genapply/Main.hs
>     index 71b84fde79..7038dc5c09 100644
>     --- a/utils/genapply/Main.hs
>     +++ b/utils/genapply/Main.hs
>     @@ -903,7 +903,7 @@ genStackApply regstatus args =
>      --
>      -- These code fragments are used to save registers on the stack at a heap
>      -- check failure in the entry code for a function.  We also have to save R1
>     --- and the return address (stg_gc_fun_info) on the stack.  See
> stg_gc_fun_gen
>     +-- and the return address (stg_gc_fun_info) on the stack.  See __stg_gc_fun
>      -- in HeapStackCheck.cmm for more details.
>
> I'm guessing that Gitlab is confused by the `---` prefix in the diff.
>
> I was going to report it but I realized that we're not using the latest version
> (the "help" page says "update asap"), so perhaps we should try updating first?

I have upgraded GitLab and it appears that the issue persists. Perhaps
you could open GitLab ticket and reply with a reference? I suspect we
will be hitting this quite often.

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/20190116/ad53be40/attachment.sig>

From matthewtpickering at gmail.com  Wed Jan 16 14:33:38 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 16 Jan 2019 14:33:38 +0000
Subject: Drop into a nix shell with ghcHEAD
Message-ID: <CALuQ0m-BHsxoGLFmir_qrdQ5aR1WZ6HjPCeZA3QNC1iOS6QnWw@mail.gmail.com>

Hi all,

I have written a devastating new script which makes it easy to test
snippets and packages with build artefacts built by the gitlab CI. One
invocation of `nix-shell` will enter an environment with the most
recent build artefact from master.

Usage:

```
> nix-shell https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
unpacking 'https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'...
<lots more output>
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.7.20190115
```

Repo: https://github.com/mpickering/ghc-artefact-nix

So far we have tested it works on NixOS and darwin but support for
other platforms that nix supports and we build artefacts for should be
easy. It might already work on i386 and aarch64 as well but I didn't
test these.

Cheers,

Matt

From ben at well-typed.com  Wed Jan 16 14:48:29 2019
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 16 Jan 2019 09:48:29 -0500
Subject: [FYI] GitLab upgraded
Message-ID: <87r2dchd51.fsf@smart-cactus.org>

Hi everyone,

I have upgraded our GitLab instance. While generally the changes are
pretty minor, one significant change is that batched review comments
should now result in a single email notification.

Anyways, as always, let me know whether there is any trouble.

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/20190116/134ca74b/attachment.sig>

From simonpj at microsoft.com  Wed Jan 16 14:49:00 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 16 Jan 2019 14:49:00 +0000
Subject: MR does not merge
Message-ID: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Ben
Six days ago I submitted this MR
https://gitlab.haskell.org/ghc/ghc/merge_requests/109
Just tiny refactorings.  I said "merge when validated"
But six days later, it still appears not to have merged.  What's up?  I was expecting it to merge in a matter of an hour or two.
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190116/a56716f4/attachment.html>

From matthewtpickering at gmail.com  Wed Jan 16 14:55:33 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 16 Jan 2019 14:55:33 +0000
Subject: MR does not merge
In-Reply-To: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>

There is problem with the interaction between "merge when validated"
and "fast forward merge only" option.

If anyone commits to master between clicking the button and validation
finishing then the merge will fail as the patch needs to be rebased
before it can be merged.

I'm not sure what the plan to deal with this is.

On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> Ben
>
> Six days ago I submitted this MR
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/109
>
> Just tiny refactorings.  I said “merge when validated”
>
> But six days later, it still appears not to have merged.  What’s up?  I was expecting it to merge in a matter of an hour or two.
>
> Thanks
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Wed Jan 16 14:58:57 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 16 Jan 2019 14:58:57 +0000
Subject: MR does not merge
In-Reply-To: <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
Message-ID: <AM0PR83MB030858F7510C70E7AD337AE6AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>

But a key aspect of our workflow is:

* Make a patch, discuss review etc.
* Validate it locally
* Fire and forget (expect email if it fails to merge)

If not that, then how *can* I get a patch committed?

In parallel, might someone commit the MR below?

Simon

|  -----Original Message-----
|  From: Matthew Pickering <matthewtpickering at gmail.com>
|  Sent: 16 January 2019 14:56
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Ben Gamari <ben at well-typed.com>; ghc-devs at haskell.org
|  Subject: Re: MR does not merge
|  
|  There is problem with the interaction between "merge when validated"
|  and "fast forward merge only" option.
|  
|  If anyone commits to master between clicking the button and validation
|  finishing then the merge will fail as the patch needs to be rebased
|  before it can be merged.
|  
|  I'm not sure what the plan to deal with this is.
|  
|  On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org> wrote:
|  >
|  > Ben
|  >
|  > Six days ago I submitted this MR
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F109&amp;data=02%7C01%7Cs
|  > imonpj%40microsoft.com%7C63dabcb38771412f95b308d67bc2b2cc%7C72f988bf86
|  > f141af91ab2d7cd011db47%7C1%7C0%7C636832473503704904&amp;sdata=sJ2YvYGP
|  > jRanq7nhP1IKhztYPjZA5z8629Lu2DoaFFU%3D&amp;reserved=0
|  >
|  > Just tiny refactorings.  I said “merge when validated”
|  >
|  > But six days later, it still appears not to have merged.  What’s up?  I
|  was expecting it to merge in a matter of an hour or two.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  > _______________________________________________
|  > 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%7C63dabcb38771412f95b308d67bc2b2cc%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832473503704904&amp;sdata=c1Yy
|  > oHS2yBRMtJOOK8xqLcmbYiGj%2BBPVOn5xygSWkr8%3D&amp;reserved=0

From moritz.angermann at gmail.com  Wed Jan 16 15:00:20 2019
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 16 Jan 2019 23:00:20 +0800
Subject: MR does not merge
In-Reply-To: <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
Message-ID: <F8924C86-B88A-4440-A9D0-411946D2F524@gmail.com>

I wonder if gitlab could have a feature like what bors offers. Validate and merge or [rebase and validate and merge]+. Thus eventually merging it or rejecting it due to conflict or validation failure.

Sent from my iPhone

> On 16 Jan 2019, at 10:55 PM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> There is problem with the interaction between "merge when validated"
> and "fast forward merge only" option.
> 
> If anyone commits to master between clicking the button and validation
> finishing then the merge will fail as the patch needs to be rebased
> before it can be merged.
> 
> I'm not sure what the plan to deal with this is.
> 
> On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
> <ghc-devs at haskell.org> wrote:
>> 
>> Ben
>> 
>> Six days ago I submitted this MR
>> 
>> https://gitlab.haskell.org/ghc/ghc/merge_requests/109
>> 
>> Just tiny refactorings.  I said “merge when validated”
>> 
>> But six days later, it still appears not to have merged.  What’s up?  I was expecting it to merge in a matter of an hour or two.
>> 
>> Thanks
>> 
>> 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 qdunkan at gmail.com  Wed Jan 16 15:19:48 2019
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 16 Jan 2019 23:19:48 +0800
Subject: MR does not merge
In-Reply-To: <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
Message-ID: <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>

At work we use "marge bot", https://github.com/smarkets/marge-bot
which is an automatic bot that will do the rebase and resubmit thing.
I think it's pretty essential, because otherwise any intervening merge
means you have to babysit the merge button.  It's also more efficient
if you have expensive CI, because it serializes the runs.

BTW, I've extended marge with a "try rebase, then try merge" strategy,
which is useful if people merge from head, and a "merge CI run" which
is useful if you have an expensive CI you want to run only on merge,
not on every single branch push.

On Wed, Jan 16, 2019 at 10:56 PM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> There is problem with the interaction between "merge when validated"
> and "fast forward merge only" option.
>
> If anyone commits to master between clicking the button and validation
> finishing then the merge will fail as the patch needs to be rebased
> before it can be merged.
>
> I'm not sure what the plan to deal with this is.
>
> On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
> <ghc-devs at haskell.org> wrote:
> >
> > Ben
> >
> > Six days ago I submitted this MR
> >
> > https://gitlab.haskell.org/ghc/ghc/merge_requests/109
> >
> > Just tiny refactorings.  I said “merge when validated”
> >
> > But six days later, it still appears not to have merged.  What’s up?  I was expecting it to merge in a matter of an hour or two.
> >
> > Thanks
> >
> > 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 lonetiger at gmail.com  Wed Jan 16 21:22:52 2019
From: lonetiger at gmail.com (Phyx)
Date: Wed, 16 Jan 2019 21:22:52 +0000
Subject: MR does not merge
In-Reply-To: <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
 <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
Message-ID: <CABHktDXUHqcO3m2wLr7+hzgBySFWF=KwjMshGoPJb3VJEVp7UQ@mail.gmail.com>

The problem is with the different platforms that need to be tested. I could
see this getting stuck in an infinite retest and rebase loop because you
have to wait on different builds to finish not just one.

So I think this is a harder problem to solve than we're making it out to
be. The system needs some concept of fairness and prevention of this retry
cycle. And you can't not retest the patch after a rebase as the
functionality of the already merged patch may be conflicting.

I imagine the bit cannot serialize all testing on all platforms otherwise
the slowest platform becomes the problem.

On Wed, Jan 16, 2019, 15:20 Evan Laforge <qdunkan at gmail.com> wrote:

> At work we use "marge bot", https://github.com/smarkets/marge-bot
> which is an automatic bot that will do the rebase and resubmit thing.
> I think it's pretty essential, because otherwise any intervening merge
> means you have to babysit the merge button.  It's also more efficient
> if you have expensive CI, because it serializes the runs.
>
> BTW, I've extended marge with a "try rebase, then try merge" strategy,
> which is useful if people merge from head, and a "merge CI run" which
> is useful if you have an expensive CI you want to run only on merge,
> not on every single branch push.
>
> On Wed, Jan 16, 2019 at 10:56 PM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
> >
> > There is problem with the interaction between "merge when validated"
> > and "fast forward merge only" option.
> >
> > If anyone commits to master between clicking the button and validation
> > finishing then the merge will fail as the patch needs to be rebased
> > before it can be merged.
> >
> > I'm not sure what the plan to deal with this is.
> >
> > On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
> > <ghc-devs at haskell.org> wrote:
> > >
> > > Ben
> > >
> > > Six days ago I submitted this MR
> > >
> > > https://gitlab.haskell.org/ghc/ghc/merge_requests/109
> > >
> > > Just tiny refactorings.  I said “merge when validated”
> > >
> > > But six days later, it still appears not to have merged.  What’s up?
> I was expecting it to merge in a matter of an hour or two.
> > >
> > > Thanks
> > >
> > > 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
> _______________________________________________
> 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/20190116/be87cdc9/attachment.html>

From chessai1996 at gmail.com  Thu Jan 17 03:49:11 2019
From: chessai1996 at gmail.com (chessai .)
Date: Wed, 16 Jan 2019 22:49:11 -0500
Subject: Drop into a nix shell with ghcHEAD
In-Reply-To: <CALuQ0m-BHsxoGLFmir_qrdQ5aR1WZ6HjPCeZA3QNC1iOS6QnWw@mail.gmail.com>
References: <CALuQ0m-BHsxoGLFmir_qrdQ5aR1WZ6HjPCeZA3QNC1iOS6QnWw@mail.gmail.com>
Message-ID: <CAD34_k+XO=xdFGKsHQN7kLAxpqDsjtksiqtY_879o=8eUUOQGw@mail.gmail.com>

Beautiful. Thanks for sharing

On Wed, Jan 16, 2019 at 9:34 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi all,
>
> I have written a devastating new script which makes it easy to test
> snippets and packages with build artefacts built by the gitlab CI. One
> invocation of `nix-shell` will enter an environment with the most
> recent build artefact from master.
>
> Usage:
>
> ```
> > nix-shell
> https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
> unpacking '
> https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'...
> <lots more output>
> > ghc --version
> The Glorious Glasgow Haskell Compilation System, version 8.7.20190115
> ```
>
> Repo: https://github.com/mpickering/ghc-artefact-nix
>
> So far we have tested it works on NixOS and darwin but support for
> other platforms that nix supports and we build artefacts for should be
> easy. It might already work on i386 and aarch64 as well but I didn't
> test these.
>
> Cheers,
>
> Matt
> _______________________________________________
> 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/20190116/46214f8f/attachment.html>

From simonpj at microsoft.com  Thu Jan 17 12:41:42 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Jan 2019 12:41:42 +0000
Subject: MR does not merge
In-Reply-To: <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
 <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
Message-ID: <AM0PR83MB03082675FE3E4A97D3E907ACAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>

To me it seems clear that GUARANTEEING that a patch won't break the master branch is difficult; it serialises all patches, and it may require many iterations.

Here's an obvious alternative for the "merge to master" pipeline;

1. Rebase the MR on master.  If that fails, send email to the author.

2. Full validate.  If that fails, send email to the author.

3. Rebase on master again (if master has changed). If that fails,
   send email to author

4. Commit to master

Note that

* There is a small possibility that changes between starting (2) and
  finishing (3) will meant that, even though (3) succeeds cleanly, there
  is a semantic bug that means that the result fails.

  But it is extremely unlikely.  And if it does happen, all subsequent
  builds will fail, so we'll soon know.  Belt-and-braces: you could validate
  the result of (4) so that blame is always correctly attributed.

* The process is highly parallel.  You can be validating multiple patches
  at the same time, in stark contrast to the completely serial nature of
  our current story.

Can Gitlab do this?

Simon

|  -----Original Message-----
|  From: Evan Laforge <qdunkan at gmail.com>
|  Sent: 16 January 2019 15:20
|  To: Matthew Pickering <matthewtpickering at gmail.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
|  Subject: Re: MR does not merge
|  
|  At work we use "marge bot",
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
|  com%2Fsmarkets%2Fmarge-
|  bot&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d6
|  7bc614f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&
|  amp;sdata=f99fNqu5kgFuFK%2BUEU8d3Z4JDlQek1yYuY2OM9AMFf8%3D&amp;reserved=0
|  which is an automatic bot that will do the rebase and resubmit thing.
|  I think it's pretty essential, because otherwise any intervening merge
|  means you have to babysit the merge button.  It's also more efficient if
|  you have expensive CI, because it serializes the runs.
|  
|  BTW, I've extended marge with a "try rebase, then try merge" strategy,
|  which is useful if people merge from head, and a "merge CI run" which is
|  useful if you have an expensive CI you want to run only on merge, not on
|  every single branch push.
|  
|  On Wed, Jan 16, 2019 at 10:56 PM Matthew Pickering
|  <matthewtpickering at gmail.com> wrote:
|  >
|  > There is problem with the interaction between "merge when validated"
|  > and "fast forward merge only" option.
|  >
|  > If anyone commits to master between clicking the button and validation
|  > finishing then the merge will fail as the patch needs to be rebased
|  > before it can be merged.
|  >
|  > I'm not sure what the plan to deal with this is.
|  >
|  > On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
|  > <ghc-devs at haskell.org> wrote:
|  > >
|  > > Ben
|  > >
|  > > Six days ago I submitted this MR
|  > >
|  > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
|  > > tlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F109&amp;data=02%7C01
|  > > %7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f9
|  > > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=
|  > > OjHtPXsIpjeW7tPJvheT%2F4hh4aOW7h82bdcifdQ6cfA%3D&amp;reserved=0
|  > >
|  > > Just tiny refactorings.  I said “merge when validated”
|  > >
|  > > But six days later, it still appears not to have merged.  What’s up?
|  I was expecting it to merge in a matter of an hour or two.
|  > >
|  > > Thanks
|  > >
|  > > Simon
|  > >
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org
|  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
|  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
|  > > 7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C
|  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sd
|  > > ata=AxazRR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserve
|  > > d=0
|  > _______________________________________________
|  > 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%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=Axaz
|  > RR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserved=0

From rae at cs.brynmawr.edu  Thu Jan 17 13:12:07 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 17 Jan 2019 08:12:07 -0500
Subject: MR does not merge
In-Reply-To: <AM0PR83MB03082675FE3E4A97D3E907ACAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
 <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
 <AM0PR83MB03082675FE3E4A97D3E907ACAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <A77F92EB-AE46-4E87-907C-8BE14D78A5C7@cs.brynmawr.edu>

+1 on Simon's plan. I explicitly agree with the move not to validate before the final commit (if a rebase is necessary); note that the successful rebase is guaranteed not to have any conflicts (or else step 3 would have failed). We should continue to do CI on the commits that have actually landed, so the final result is validated.

And here's another idea to grease the wheels: I imagine the majority of commits have essentially no chance of showing breakage in the variety of platforms/build methods that we have. Right now, we have [skip ci] as a way of telling the infrastructure to skip. What if we had [full ci] requesting that all the different configurations were run before merging? Without [full ci], only the Linux validation would take place; if that's green, merge. Regardless of the setting of [full ci], the full CI matrix would be run after merging. (IIUC, this is different than [skip ci], which also stops CI from happening after the merge.) Note that this new plan requires opt-in when the author is worried about breakage, but would still catch breakage ere long when the full CI matrix is run after merging. In the meantime, even if full CI fails and the patch author is working on fixing it, the rest of us still know that the build succeeds at least on Linux, so we can continue to plow forward. (Except maybe for Simon. Sorry, Simon.)

I don't know if this new idea is necessary, but it might clear logjams if we notice that they happen often.

Richard

> On Jan 17, 2019, at 7:41 AM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> To me it seems clear that GUARANTEEING that a patch won't break the master branch is difficult; it serialises all patches, and it may require many iterations.
> 
> Here's an obvious alternative for the "merge to master" pipeline;
> 
> 1. Rebase the MR on master.  If that fails, send email to the author.
> 
> 2. Full validate.  If that fails, send email to the author.
> 
> 3. Rebase on master again (if master has changed). If that fails,
>   send email to author
> 
> 4. Commit to master
> 
> Note that
> 
> * There is a small possibility that changes between starting (2) and
>  finishing (3) will meant that, even though (3) succeeds cleanly, there
>  is a semantic bug that means that the result fails.
> 
>  But it is extremely unlikely.  And if it does happen, all subsequent
>  builds will fail, so we'll soon know.  Belt-and-braces: you could validate
>  the result of (4) so that blame is always correctly attributed.
> 
> * The process is highly parallel.  You can be validating multiple patches
>  at the same time, in stark contrast to the completely serial nature of
>  our current story.
> 
> Can Gitlab do this?
> 
> Simon
> 
> |  -----Original Message-----
> |  From: Evan Laforge <qdunkan at gmail.com>
> |  Sent: 16 January 2019 15:20
> |  To: Matthew Pickering <matthewtpickering at gmail.com>
> |  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
> |  Subject: Re: MR does not merge
> |  
> |  At work we use "marge bot",
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> |  com%2Fsmarkets%2Fmarge-
> |  bot&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d6
> |  7bc614f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&
> |  amp;sdata=f99fNqu5kgFuFK%2BUEU8d3Z4JDlQek1yYuY2OM9AMFf8%3D&amp;reserved=0
> |  which is an automatic bot that will do the rebase and resubmit thing.
> |  I think it's pretty essential, because otherwise any intervening merge
> |  means you have to babysit the merge button.  It's also more efficient if
> |  you have expensive CI, because it serializes the runs.
> |  
> |  BTW, I've extended marge with a "try rebase, then try merge" strategy,
> |  which is useful if people merge from head, and a "merge CI run" which is
> |  useful if you have an expensive CI you want to run only on merge, not on
> |  every single branch push.
> |  
> |  On Wed, Jan 16, 2019 at 10:56 PM Matthew Pickering
> |  <matthewtpickering at gmail.com> wrote:
> |  >
> |  > There is problem with the interaction between "merge when validated"
> |  > and "fast forward merge only" option.
> |  >
> |  > If anyone commits to master between clicking the button and validation
> |  > finishing then the merge will fail as the patch needs to be rebased
> |  > before it can be merged.
> |  >
> |  > I'm not sure what the plan to deal with this is.
> |  >
> |  > On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
> |  > <ghc-devs at haskell.org> wrote:
> |  > >
> |  > > Ben
> |  > >
> |  > > Six days ago I submitted this MR
> |  > >
> |  > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> |  > > tlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F109&amp;data=02%7C01
> |  > > %7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f9
> |  > > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=
> |  > > OjHtPXsIpjeW7tPJvheT%2F4hh4aOW7h82bdcifdQ6cfA%3D&amp;reserved=0
> |  > >
> |  > > Just tiny refactorings.  I said “merge when validated”
> |  > >
> |  > > But six days later, it still appears not to have merged.  What’s up?
> |  I was expecting it to merge in a matter of an hour or two.
> |  > >
> |  > > Thanks
> |  > >
> |  > > Simon
> |  > >
> |  > > _______________________________________________
> |  > > ghc-devs mailing list
> |  > > ghc-devs at haskell.org
> |  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
> |  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
> |  > > 7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C
> |  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sd
> |  > > ata=AxazRR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserve
> |  > > d=0
> |  > _______________________________________________
> |  > 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%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=Axaz
> |  > RR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserved=0
> _______________________________________________
> 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 Jan 17 14:02:00 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 17 Jan 2019 14:02:00 +0000
Subject: MR does not merge
In-Reply-To: <A77F92EB-AE46-4E87-907C-8BE14D78A5C7@cs.brynmawr.edu>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
 <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
 <AM0PR83MB03082675FE3E4A97D3E907ACAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <A77F92EB-AE46-4E87-907C-8BE14D78A5C7@cs.brynmawr.edu>
Message-ID: <CALuQ0m9zxhTo9PkMSxJw5ck2C6rR3hEY2ie7cQXwmq693ZcqfA@mail.gmail.com>

I am against any proposed change which makes it easier to break the
build on any platform. Someone, usually Ben, has to waste a lot of
time fixing these breakages and if master does not build it affects
every developer.

If a commit breaks the build then it should prevent the patch being
merged. Now that CI is robust, this is a realistic goal.

My preferred solution is to start using "marge-bot" which is battle
tested solution for this precise problem. We don't need to reinvent
our own solution. Hopefully the native support in gitlab will improve
over time but for now it is the highest impact change we can make
whilst maintaining the core principles of CI.

Cheers,

Matt

On Thu, Jan 17, 2019 at 1:12 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
> +1 on Simon's plan. I explicitly agree with the move not to validate before the final commit (if a rebase is necessary); note that the successful rebase is guaranteed not to have any conflicts (or else step 3 would have failed). We should continue to do CI on the commits that have actually landed, so the final result is validated.
>
> And here's another idea to grease the wheels: I imagine the majority of commits have essentially no chance of showing breakage in the variety of platforms/build methods that we have. Right now, we have [skip ci] as a way of telling the infrastructure to skip. What if we had [full ci] requesting that all the different configurations were run before merging? Without [full ci], only the Linux validation would take place; if that's green, merge. Regardless of the setting of [full ci], the full CI matrix would be run after merging. (IIUC, this is different than [skip ci], which also stops CI from happening after the merge.) Note that this new plan requires opt-in when the author is worried about breakage, but would still catch breakage ere long when the full CI matrix is run after merging. In the meantime, even if full CI fails and the patch author is working on fixing it, the rest of us still know that the build succeeds at least on Linux, so we can continue to plow forward. (Except maybe for Simon. Sorry, Simon.)
>
> I don't know if this new idea is necessary, but it might clear logjams if we notice that they happen often.
>
> Richard
>
> > On Jan 17, 2019, at 7:41 AM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> >
> > To me it seems clear that GUARANTEEING that a patch won't break the master branch is difficult; it serialises all patches, and it may require many iterations.
> >
> > Here's an obvious alternative for the "merge to master" pipeline;
> >
> > 1. Rebase the MR on master.  If that fails, send email to the author.
> >
> > 2. Full validate.  If that fails, send email to the author.
> >
> > 3. Rebase on master again (if master has changed). If that fails,
> >   send email to author
> >
> > 4. Commit to master
> >
> > Note that
> >
> > * There is a small possibility that changes between starting (2) and
> >  finishing (3) will meant that, even though (3) succeeds cleanly, there
> >  is a semantic bug that means that the result fails.
> >
> >  But it is extremely unlikely.  And if it does happen, all subsequent
> >  builds will fail, so we'll soon know.  Belt-and-braces: you could validate
> >  the result of (4) so that blame is always correctly attributed.
> >
> > * The process is highly parallel.  You can be validating multiple patches
> >  at the same time, in stark contrast to the completely serial nature of
> >  our current story.
> >
> > Can Gitlab do this?
> >
> > Simon
> >
> > |  -----Original Message-----
> > |  From: Evan Laforge <qdunkan at gmail.com>
> > |  Sent: 16 January 2019 15:20
> > |  To: Matthew Pickering <matthewtpickering at gmail.com>
> > |  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
> > |  Subject: Re: MR does not merge
> > |
> > |  At work we use "marge bot",
> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> > |  com%2Fsmarkets%2Fmarge-
> > |  bot&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d6
> > |  7bc614f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&
> > |  amp;sdata=f99fNqu5kgFuFK%2BUEU8d3Z4JDlQek1yYuY2OM9AMFf8%3D&amp;reserved=0
> > |  which is an automatic bot that will do the rebase and resubmit thing.
> > |  I think it's pretty essential, because otherwise any intervening merge
> > |  means you have to babysit the merge button.  It's also more efficient if
> > |  you have expensive CI, because it serializes the runs.
> > |
> > |  BTW, I've extended marge with a "try rebase, then try merge" strategy,
> > |  which is useful if people merge from head, and a "merge CI run" which is
> > |  useful if you have an expensive CI you want to run only on merge, not on
> > |  every single branch push.
> > |
> > |  On Wed, Jan 16, 2019 at 10:56 PM Matthew Pickering
> > |  <matthewtpickering at gmail.com> wrote:
> > |  >
> > |  > There is problem with the interaction between "merge when validated"
> > |  > and "fast forward merge only" option.
> > |  >
> > |  > If anyone commits to master between clicking the button and validation
> > |  > finishing then the merge will fail as the patch needs to be rebased
> > |  > before it can be merged.
> > |  >
> > |  > I'm not sure what the plan to deal with this is.
> > |  >
> > |  > On Wed, Jan 16, 2019 at 2:49 PM Simon Peyton Jones via ghc-devs
> > |  > <ghc-devs at haskell.org> wrote:
> > |  > >
> > |  > > Ben
> > |  > >
> > |  > > Six days ago I submitted this MR
> > |  > >
> > |  > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > |  > > tlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F109&amp;data=02%7C01
> > |  > > %7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f9
> > |  > > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=
> > |  > > OjHtPXsIpjeW7tPJvheT%2F4hh4aOW7h82bdcifdQ6cfA%3D&amp;reserved=0
> > |  > >
> > |  > > Just tiny refactorings.  I said “merge when validated”
> > |  > >
> > |  > > But six days later, it still appears not to have merged.  What’s up?
> > |  I was expecting it to merge in a matter of an hour or two.
> > |  > >
> > |  > > Thanks
> > |  > >
> > |  > > Simon
> > |  > >
> > |  > > _______________________________________________
> > |  > > ghc-devs mailing list
> > |  > > ghc-devs at haskell.org
> > |  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
> > |  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
> > |  > > 7C01%7Csimonpj%40microsoft.com%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C
> > |  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sd
> > |  > > ata=AxazRR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserve
> > |  > > d=0
> > |  > _______________________________________________
> > |  > 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%7Cb0a1fe00d27e4879ae1e08d67bc614f2%7C72f988
> > |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636832488027160974&amp;sdata=Axaz
> > |  > RR%2FEUVEB93FYHAaLig%2FYPBR%2BLH9eAciYs5NTaNU%3D&amp;reserved=0
> > _______________________________________________
> > 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  Thu Jan 17 15:09:33 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 17 Jan 2019 10:09:33 -0500
Subject: MR does not merge
In-Reply-To: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <8736prgw2g.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Ben
>
> Six days ago I submitted this MR
> https://gitlab.haskell.org/ghc/ghc/merge_requests/109
> Just tiny refactorings.  I said "merge when validated"
> But six days later, it still appears not to have merged. What's up? I
> was expecting it to merge in a matter of an hour or two.

Indeed this is a known issue that I have been working [1] with upstream
to resolve. A fix, which looks similar to the plan you propse, is
milestoned for the May release. In the meantime I have been handling
merging manually as I did under Phabricator: batch up mergeable MRs into
a merge branch, push the merge branch for CI, and merge it after it
validates.

Marge bot [2], mentioned by Evan, is another workaround for this
issue.However, my understanding is that it is unnecessarily serial which
I feared may slow the rate of merge. We could consider using it until a
proper upstream solution arrives, however.

In general I agree with Matthew that we should try very hard to avoid
ever merging broken code; the cost of bad patches is extremely high. The
solution that GitLab is looking to implement maintains a stack of MRs to
be merged, optimistically assuming that all will pass CI. When a new MR
is requested to be merged it is rebased onto the end of the stack and CI
jobs are started. This allows it to avoid testing commits serially. If
an MR low in the stack fails then it is dropped from the stack, all MRs
above it are rebased, and retested.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186
[2] https://github.com/smarkets/marge-bot
-------------- 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/20190117/bd89bcea/attachment.sig>

From ben at smart-cactus.org  Thu Jan 17 15:22:44 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 17 Jan 2019 10:22:44 -0500
Subject: MR does not merge
In-Reply-To: <CALuQ0m9zxhTo9PkMSxJw5ck2C6rR3hEY2ie7cQXwmq693ZcqfA@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CALuQ0m-CgB202PLUH=uLhjaWY7_DYrM+D0-xNrrG-Zz86+YpcA@mail.gmail.com>
 <CACbaDy5t7PxGWu_-31yaWCkx_v5tJLRgpq8thEdc=bM+SLpBkA@mail.gmail.com>
 <AM0PR83MB03082675FE3E4A97D3E907ACAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <A77F92EB-AE46-4E87-907C-8BE14D78A5C7@cs.brynmawr.edu>
 <CALuQ0m9zxhTo9PkMSxJw5ck2C6rR3hEY2ie7cQXwmq693ZcqfA@mail.gmail.com>
Message-ID: <87y37jfgw0.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> I am against any proposed change which makes it easier to break the
> build on any platform. Someone, usually Ben, has to waste a lot of
> time fixing these breakages and if master does not build it affects
> every developer.
>
Indeed, I agree with Matthew here. Breakages are very painful both when
they happen and after when we need to bisect through them.

> If a commit breaks the build then it should prevent the patch being
> merged. Now that CI is robust, this is a realistic goal.
>
> My preferred solution is to start using "marge-bot" which is battle
> tested solution for this precise problem. We don't need to reinvent
> our own solution. Hopefully the native support in gitlab will improve
> over time but for now it is the highest impact change we can make
> whilst maintaining the core principles of CI.
>
I would be fine with trying to deploy it. My thought was that it would
be "only" a few months of manually working around the issue until an
upstream solution arrived. However, I agree that this may be just long
enough to justify deploying an interim solution.

I can try this today if others agree this is a reasonable way forward.

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/20190117/d8ad175d/attachment.sig>

From simonpj at microsoft.com  Thu Jan 17 16:11:50 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Jan 2019 16:11:50 +0000
Subject: MR does not merge
In-Reply-To: <8736prgw2g.fsf@smart-cactus.org>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736prgw2g.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB0308F47F0516B551B5D902C5AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  Indeed this is a known issue that I have been working [1] with upstream
|  to resolve.

Thanks.  I'm not equipped to express a well-informed opinion about what the best thing to do is.  But in the meantime I WOULD be grateful for explicit workflow advice.  Specifically:

* What steps should I take to get a patch committed to master,
  assuming I've done the review stuff and want to press "go"?

Meanwhile, could you commit MR 109 please?

Simon

|  -----Original Message-----
|  From: Ben Gamari <ben at well-typed.com>
|  Sent: 17 January 2019 15:10
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: MR does not merge
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
|  
|  > Ben
|  >
|  > Six days ago I submitted this MR
|  > https://gitlab.haskell.org/ghc/ghc/merge_requests/109
|  > Just tiny refactorings.  I said "merge when validated"
|  > But six days later, it still appears not to have merged. What's up? I
|  > was expecting it to merge in a matter of an hour or two.
|  
|  Indeed this is a known issue that I have been working [1] with upstream
|  to resolve. A fix, which looks similar to the plan you propse, is
|  milestoned for the May release. In the meantime I have been handling
|  merging manually as I did under Phabricator: batch up mergeable MRs into
|  a merge branch, push the merge branch for CI, and merge it after it
|  validates.
|  
|  Marge bot [2], mentioned by Evan, is another workaround for this
|  issue.However, my understanding is that it is unnecessarily serial which
|  I feared may slow the rate of merge. We could consider using it until a
|  proper upstream solution arrives, however.
|  
|  In general I agree with Matthew that we should try very hard to avoid
|  ever merging broken code; the cost of bad patches is extremely high. The
|  solution that GitLab is looking to implement maintains a stack of MRs to
|  be merged, optimistically assuming that all will pass CI. When a new MR
|  is requested to be merged it is rebased onto the end of the stack and CI
|  jobs are started. This allows it to avoid testing commits serially. If an
|  MR low in the stack fails then it is dropped from the stack, all MRs
|  above it are rebased, and retested.
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186
|  [2] https://github.com/smarkets/marge-bot

From simonpj at microsoft.com  Thu Jan 17 16:25:47 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Jan 2019 16:25:47 +0000
Subject: Gitlab notifications
Message-ID: <AM0PR83MB030881E3E481D37B258217BEAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I don't seem to be receiving notifications for my own MR:
https://gitlab.haskell.org/ghc/ghc/merge_requests/128
Richard and Ryan both commented, but I received literally no email about it.
I'm set to "Watch" the GHC project.
Any ideas?
Simon
PS: I am getting some notifications

  *   Thurs (today): 3 emails, about !79, !133
  *   Weds: 6 emails about !51, !125, !124
  *   Tues: 22 messages about a variety of tickets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190117/c62a239f/attachment.html>

From ben at smart-cactus.org  Thu Jan 17 16:35:06 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 17 Jan 2019 11:35:06 -0500
Subject: Gitlab notifications
In-Reply-To: <AM0PR83MB030881E3E481D37B258217BEAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB030881E3E481D37B258217BEAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87imynfdjc.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> I don't seem to be receiving notifications for my own MR:
> https://gitlab.haskell.org/ghc/ghc/merge_requests/128
> Richard and Ryan both commented, but I received literally no email about it.
> I'm set to "Watch" the GHC project.

Sigh, I thought I had fixed this earlier this morning. However, it seems
something is still awry from the update. Investigating.

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/20190117/4db12060/attachment.sig>

From chessai1996 at gmail.com  Thu Jan 17 21:28:33 2019
From: chessai1996 at gmail.com (chessai .)
Date: Thu, 17 Jan 2019 16:28:33 -0500
Subject: MutVar# and GC
Message-ID: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>

Devs,

I've heard from a few friends that MutVars, TVars, etc. are more
challenging for the garbage collector. I'm writing to ask if someone can
answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
writeup or documentation that mentions this. The HeapObjects trac page also
mentions nothing about these supposed difficulties that GC faces with
mutable heap objects.

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

From simonpj at microsoft.com  Thu Jan 17 22:05:04 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Jan 2019 22:05:04 +0000
Subject: [GHC] #16105: Haddock's resource directory isn't properly handled
 by Hadrian
In-Reply-To: <065.b3b59674f28ebc45341b75b84e9c2e3b@haskell.org>
References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org>
 <065.b3b59674f28ebc45341b75b84e9c2e3b@haskell.org>
Message-ID: <AM0PR83MB03080F6E3B09305A52B58BE7AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I feel as if I'm seeing the same commits many times.  Is that right?

Simon

| -----Original Message-----
| From: ghc-tickets <ghc-tickets-bounces at haskell.org> On Behalf Of GHC
| Sent: 17 January 2019 17:47
| Subject: Re: [GHC] #16105: Haddock's resource directory isn't properly
| handled by Hadrian
| 
| #16105: Haddock's resource directory isn't properly handled by Hadrian
| -------------------------------------+-------------------------------------
|         Reporter:  harpocrates       |                Owner:  harpocrates
|             Type:  bug               |               Status:  patch
|         Priority:  normal            |            Milestone:
|        Component:  Build System      |              Version:  8.6.3
|   (Hadrian)                          |
|       Resolution:                    |             Keywords:
| Operating System:  Unknown/Multiple  |         Architecture:
|                                      |  Unknown/Multiple
|  Type of failure:  None/Unknown      |            Test Case:
|       Blocked By:                    |             Blocking:
|  Related Tickets:                    |  Differential Rev(s):
|        Wiki Page:                    |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
| skell.org%2Fghc%2Fghc%2Fmerge_requests%2F107&amp;data=02%7C01%7Csimonpj%40m
| icrosoft.com%7C372045a12b644a9571cb08d67ca3db5e%7C72f988bf86f141af91ab2d7cd
| 011db47%7C1%7C0%7C636833440531332748&amp;sdata=5xl9%2FYs97X%2FZx6gFnQllwe0G
| %2F6nns48JAQLpFH%2FcptU%3D&amp;reserved=0
| -------------------------------------+-------------------------------------
| 
| Comment (by Ben Gamari <ben@…>):
| 
|  In [changeset:"2e05912086bbb8eab213d44af300ecc396d912aa/ghc" 2e05912/ghc]:
|  {{{
|  #!CommitTicketReference repository="ghc"
|  revision="2e05912086bbb8eab213d44af300ecc396d912aa"
|  Hadrian: handle Haddock's resource directory
| 
|  Fixes #16105
| 
|    * Require Haddock's resource as runtime dependencies of the Haddock
|      builder. This means we no longer have to `need` particular resources
|      in every other documentation rule.
| 
|    * Do a _tracked_ copy of both the 'html' and 'latex' folder resource
|      folders.
| 
|    * Move resources into `stage1/lib` (NB: the `haddock` binary goes in
|      `stage1/bin`). Besides now actually matching the Haddock script
|      wrapper generated by BinaryDist, this also prepares for Haddock
|      in relocatable build folder detecting its own resources.
|  }}}
| 
| --
| Ticket URL:
| <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske
| ll.org%2Ftrac%2Fghc%2Fticket%2F16105%23comment%3A4&amp;data=02%7C01%7Csimon
| pj%40microsoft.com%7C372045a12b644a9571cb08d67ca3db5e%7C72f988bf86f141af91a
| b2d7cd011db47%7C1%7C0%7C636833440531332748&amp;sdata=bYvB5fV1dorg3j1nJogVvh
| %2Fs7c4onmFfOXJXZ1ZAZj8%3D&amp;reserved=0>
| GHC
| <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haske
| ll.org%2Fghc%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C372045a12b644a
| 9571cb08d67ca3db5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683344053
| 1332748&amp;sdata=3xcWX15vR8Vcl3wNn3P%2FsM%2FeBp6nTusSMSkfs%2FXTrGo%3D&amp;
| reserved=0>
| The Glasgow Haskell Compiler

From fryguybob at gmail.com  Fri Jan 18 01:19:47 2019
From: fryguybob at gmail.com (Ryan Yates)
Date: Thu, 17 Jan 2019 20:19:47 -0500
Subject: MutVar# and GC
In-Reply-To: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>
References: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>
Message-ID: <CAO27hRq5EX2Ds5XsY74cNBtkujvWs8MaCF+NWruEMx_KEkd9ng@mail.gmail.com>

Hi,

Because GHC's GC is generational it needs a way to handle heap objects from
older generations that point into younger generations.  This only happens
when an older object is mutated to point to a younger object.  GHC solves
this by invoking the GC write barrier (not to be confused with write
barriers for memory synchronization) `dirty_MUT_VAR`.  This will add that
mutable object to a mutable list that will be traversed in minor GCs along
with young generation roots.  Additionally the write barrier will mark the
heap object as "dirty" to avoid adding it to the list more than once.

Ryan

On Thu, Jan 17, 2019 at 4:29 PM chessai . <chessai1996 at gmail.com> wrote:

> Devs,
>
> I've heard from a few friends that MutVars, TVars, etc. are more
> challenging for the garbage collector. I'm writing to ask if someone can
> answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
> writeup or documentation that mentions this. The HeapObjects trac page also
> mentions nothing about these supposed difficulties that GC faces with
> mutable heap objects.
>
> Thanks
> _______________________________________________
> 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/20190117/bb12f44c/attachment.html>

From moritz.angermann at gmail.com  Fri Jan 18 03:04:32 2019
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 18 Jan 2019 11:04:32 +0800
Subject: Hackage and ghc shipped package contents mismatch
Message-ID: <FA2688ED-5A3B-4D3A-8580-12B91FAA1135@gmail.com>

Dear friends,

the other day I've run into an issue where I could not build a package.  It turned out that
the underlying reason was that the packages ghc ships with are not necessarily the same
as they are on hackage. Ryan was kind enough to open Ticket 16199[1].

My use case is that I reduce the set of packages I use from the package database that ghc
ships, and build the others myself.  Thus if packages in the package database as shipped
with ghc do not match the ones found on hackage for the SAME VERSION, I run into issues.

I've since devised a script to compute the difference between packages in GHC and the ones
on hackage with the same version[2]. 

I've then sat out to compute the differences for ghc8.4 and ghc8.6 using the following
approach:

for release in ghc-8.4.1-release ghc-8.4.2-release ghc-8.4.3-release ghc-8.4.4-release \
               ghc-8.6.4-release ghc-8.6.2-release ghc-8.6.3-release; do
  git checkout $release
  git reset --hard HEAD && git clean -xffd
  git submodule update --init --recursive && git clean -xffd
  ../verify-packages.sh
  mkdir -p ../$release
  find package-diffs -not -empty -type f -exec cp {} ../$release \;
done

I've compiled them[3] for inspection (and because I need to patch my hackage packages to
match the ones that ghc ships).

I'm sorry to report that I found discrepancies between the package we ship with GHC and
the ones on haskell for each ghc release in 8.4 and 8.6.  Some changes are minor, such
as version bumps, as can be represented with revisions on hackage as well.  Other are not
so minor. The one over which I tripped was transformers-0.5.5.0.  The diff[4] is 20K.

I therefore propose that we make sure to only ship packages with GHC that match their
respective versions on hackage.

Cheers,
 Moritz

--
[1]: http://ghc.haskell.org/trac/ghc/ticket/16199
[2]: https://gitlab.haskell.org/ghc/ghc/merge_requests/139
[3]: https://github.com/angerman/haskell.nix/tree/master/patches
[4]: https://github.com/angerman/haskell.nix/blob/master/patches/ghc863/transformers-0.5.5.0.patch

From chessai1996 at gmail.com  Fri Jan 18 04:33:29 2019
From: chessai1996 at gmail.com (chessai .)
Date: Thu, 17 Jan 2019 23:33:29 -0500
Subject: MutVar# and GC
In-Reply-To: <CAO27hRq5EX2Ds5XsY74cNBtkujvWs8MaCF+NWruEMx_KEkd9ng@mail.gmail.com>
References: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>
 <CAO27hRq5EX2Ds5XsY74cNBtkujvWs8MaCF+NWruEMx_KEkd9ng@mail.gmail.com>
Message-ID: <CAD34_k+tmjK6EsBQ7m44rvJJydchHdbNeLRfoanwuKOg_rF78w@mail.gmail.com>

Ryan,

That makes perfect sense, thanks. Is that documented explicitly anywhere?
If not, I'd like to add the documentation to any place relevant.

Thanks

On Thu, Jan 17, 2019, 8:19 PM Ryan Yates <fryguybob at gmail.com wrote:

> Hi,
>
> Because GHC's GC is generational it needs a way to handle heap objects
> from older generations that point into younger generations.  This only
> happens when an older object is mutated to point to a younger object.  GHC
> solves this by invoking the GC write barrier (not to be confused with write
> barriers for memory synchronization) `dirty_MUT_VAR`.  This will add that
> mutable object to a mutable list that will be traversed in minor GCs along
> with young generation roots.  Additionally the write barrier will mark the
> heap object as "dirty" to avoid adding it to the list more than once.
>
> Ryan
>
> On Thu, Jan 17, 2019 at 4:29 PM chessai . <chessai1996 at gmail.com> wrote:
>
>> Devs,
>>
>> I've heard from a few friends that MutVars, TVars, etc. are more
>> challenging for the garbage collector. I'm writing to ask if someone can
>> answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
>> writeup or documentation that mentions this. The HeapObjects trac page also
>> mentions nothing about these supposed difficulties that GC faces with
>> mutable heap objects.
>>
>> Thanks
>> _______________________________________________
>> 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/20190117/f7bf0443/attachment.html>

From cheng.shao at tweag.io  Fri Jan 18 04:51:19 2019
From: cheng.shao at tweag.io (Shao, Cheng)
Date: Fri, 18 Jan 2019 12:51:19 +0800
Subject: MutVar# and GC
In-Reply-To: <CAD34_k+tmjK6EsBQ7m44rvJJydchHdbNeLRfoanwuKOg_rF78w@mail.gmail.com>
References: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>
 <CAO27hRq5EX2Ds5XsY74cNBtkujvWs8MaCF+NWruEMx_KEkd9ng@mail.gmail.com>
 <CAD34_k+tmjK6EsBQ7m44rvJJydchHdbNeLRfoanwuKOg_rF78w@mail.gmail.com>
Message-ID: <CALHrtFmoEJd+hM4T0AwrA9sbe5omW887QnCrMTTbLoOH6+VZtQ@mail.gmail.com>

Hi,

I believe it's mentioned here:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSets

Regards,
Shao Cheng

On Fri, Jan 18, 2019, 12:34 PM chessai . <chessai1996 at gmail.com> wrote:

> Ryan,
>
> That makes perfect sense, thanks. Is that documented explicitly anywhere?
> If not, I'd like to add the documentation to any place relevant.
>
> Thanks
>
> On Thu, Jan 17, 2019, 8:19 PM Ryan Yates <fryguybob at gmail.com wrote:
>
>> Hi,
>>
>> Because GHC's GC is generational it needs a way to handle heap objects
>> from older generations that point into younger generations.  This only
>> happens when an older object is mutated to point to a younger object.  GHC
>> solves this by invoking the GC write barrier (not to be confused with write
>> barriers for memory synchronization) `dirty_MUT_VAR`.  This will add that
>> mutable object to a mutable list that will be traversed in minor GCs along
>> with young generation roots.  Additionally the write barrier will mark the
>> heap object as "dirty" to avoid adding it to the list more than once.
>>
>> Ryan
>>
>> On Thu, Jan 17, 2019 at 4:29 PM chessai . <chessai1996 at gmail.com> wrote:
>>
>>> Devs,
>>>
>>> I've heard from a few friends that MutVars, TVars, etc. are more
>>> challenging for the garbage collector. I'm writing to ask if someone can
>>> answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
>>> writeup or documentation that mentions this. The HeapObjects trac page also
>>> mentions nothing about these supposed difficulties that GC faces with
>>> mutable heap objects.
>>>
>>> Thanks
>>> _______________________________________________
>>> 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/20190118/a66ba7c5/attachment.html>

From chessai1996 at gmail.com  Fri Jan 18 05:05:05 2019
From: chessai1996 at gmail.com (chessai .)
Date: Fri, 18 Jan 2019 00:05:05 -0500
Subject: MutVar# and GC
In-Reply-To: <CALHrtFmoEJd+hM4T0AwrA9sbe5omW887QnCrMTTbLoOH6+VZtQ@mail.gmail.com>
References: <CAD34_kKOpDpOX9y_CUiL1ps68mkBRpAiii9qQ4iZ5Zw=VXmxWA@mail.gmail.com>
 <CAO27hRq5EX2Ds5XsY74cNBtkujvWs8MaCF+NWruEMx_KEkd9ng@mail.gmail.com>
 <CAD34_k+tmjK6EsBQ7m44rvJJydchHdbNeLRfoanwuKOg_rF78w@mail.gmail.com>
 <CALHrtFmoEJd+hM4T0AwrA9sbe5omW887QnCrMTTbLoOH6+VZtQ@mail.gmail.com>
Message-ID: <CAD34_kLFTV93O=2GkqBumOjLF1dSRJUFcLLukLOfNjOCyZu=bw@mail.gmail.com>

Cheng,

That's perfect. Thanks

On Thu, Jan 17, 2019, 11:51 PM Shao, Cheng <cheng.shao at tweag.io wrote:

> Hi,
>
> I believe it's mentioned here:
>
>
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSets
>
> Regards,
> Shao Cheng
>
> On Fri, Jan 18, 2019, 12:34 PM chessai . <chessai1996 at gmail.com> wrote:
>
>> Ryan,
>>
>> That makes perfect sense, thanks. Is that documented explicitly anywhere?
>> If not, I'd like to add the documentation to any place relevant.
>>
>> Thanks
>>
>> On Thu, Jan 17, 2019, 8:19 PM Ryan Yates <fryguybob at gmail.com wrote:
>>
>>> Hi,
>>>
>>> Because GHC's GC is generational it needs a way to handle heap objects
>>> from older generations that point into younger generations.  This only
>>> happens when an older object is mutated to point to a younger object.  GHC
>>> solves this by invoking the GC write barrier (not to be confused with write
>>> barriers for memory synchronization) `dirty_MUT_VAR`.  This will add that
>>> mutable object to a mutable list that will be traversed in minor GCs along
>>> with young generation roots.  Additionally the write barrier will mark the
>>> heap object as "dirty" to avoid adding it to the list more than once.
>>>
>>> Ryan
>>>
>>> On Thu, Jan 17, 2019 at 4:29 PM chessai . <chessai1996 at gmail.com> wrote:
>>>
>>>> Devs,
>>>>
>>>> I've heard from a few friends that MutVars, TVars, etc. are more
>>>> challenging for the garbage collector. I'm writing to ask if someone can
>>>> answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
>>>> writeup or documentation that mentions this. The HeapObjects trac page also
>>>> mentions nothing about these supposed difficulties that GC faces with
>>>> mutable heap objects.
>>>>
>>>> Thanks
>>>> _______________________________________________
>>>> 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/20190118/1c7865ab/attachment-0001.html>

From ben at well-typed.com  Fri Jan 18 15:41:58 2019
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 18 Jan 2019 10:41:58 -0500
Subject: MR does not merge
In-Reply-To: <AM0PR83MB0308F47F0516B551B5D902C5AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736prgw2g.fsf@smart-cactus.org>
 <AM0PR83MB0308F47F0516B551B5D902C5AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <875zumezwf.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> |  Indeed this is a known issue that I have been working [1] with upstream
> |  to resolve.
>
> Thanks. I'm not equipped to express a well-informed opinion about what
> the best thing to do is. But in the meantime I WOULD be grateful for
> explicit workflow advice. Specifically:
>
> * What steps should I take to get a patch committed to master,
>   assuming I've done the review stuff and want to press "go"?
>
At the moment it's largely just a matter of when a bulk merge happens; I
did a large merge on Wednesday and another yesterday. 

However, as Matthew suggested I think it may make sense to try using
Marge bot to eliminate this manual process with little cost. It doesn't
take particularly long to put together a bulk merge but it does require
some form of human intervention which generally implies latency.

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/20190118/d6d90c1b/attachment.sig>

From ben at smart-cactus.org  Fri Jan 18 16:10:35 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 18 Jan 2019 11:10:35 -0500
Subject: Hackage and ghc shipped package contents mismatch
In-Reply-To: <FA2688ED-5A3B-4D3A-8580-12B91FAA1135@gmail.com>
References: <FA2688ED-5A3B-4D3A-8580-12B91FAA1135@gmail.com>
Message-ID: <8736pqeyl6.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Dear friends,
>
> the other day I've run into an issue where I could not build a package.  It turned out that
> the underlying reason was that the packages ghc ships with are not necessarily the same
> as they are on hackage. Ryan was kind enough to open Ticket 16199[1].
>
> My use case is that I reduce the set of packages I use from the package database that ghc
> ships, and build the others myself.  Thus if packages in the package database as shipped
> with ghc do not match the ones found on hackage for the SAME VERSION, I run into issues.
>
> I've since devised a script to compute the difference between packages in GHC and the ones
> on hackage with the same version[2]. 
>
> I've then sat out to compute the differences for ghc8.4 and ghc8.6 using the following
> approach:
>
> for release in ghc-8.4.1-release ghc-8.4.2-release ghc-8.4.3-release ghc-8.4.4-release \
>                ghc-8.6.4-release ghc-8.6.2-release ghc-8.6.3-release; do
>   git checkout $release
>   git reset --hard HEAD && git clean -xffd
>   git submodule update --init --recursive && git clean -xffd
>   ../verify-packages.sh
>   mkdir -p ../$release
>   find package-diffs -not -empty -type f -exec cp {} ../$release \;
> done
>
> I've compiled them[3] for inspection (and because I need to patch my hackage packages to
> match the ones that ghc ships).
>
> I'm sorry to report that I found discrepancies between the package we ship with GHC and
> the ones on haskell for each ghc release in 8.4 and 8.6.  Some changes are minor, such
> as version bumps, as can be represented with revisions on hackage as well.  Other are not
> so minor. The one over which I tripped was transformers-0.5.5.0.  The diff[4] is 20K.
>
This is very concerning.

> I therefore propose that we make sure to only ship packages with GHC that match their
> respective versions on hackage.
>
To be clear, this is already our policy. The problem is that we have
historically had no mechanical checking that this is in fact the case
and synchronizing with upstreams is inevitably a messy process.
Your script will help considerably.

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/20190118/ac111f5d/attachment.sig>

From ben at smart-cactus.org  Fri Jan 18 17:50:34 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 18 Jan 2019 12:50:34 -0500
Subject: Gitlab notifications
In-Reply-To: <AM0PR83MB030881E3E481D37B258217BEAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB030881E3E481D37B258217BEAD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87zhrxety2.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> I don't seem to be receiving notifications for my own MR:
> https://gitlab.haskell.org/ghc/ghc/merge_requests/128
> Richard and Ryan both commented, but I received literally no email about it.
> I'm set to "Watch" the GHC project.

Simon, can you confirm that you are now receiving notifications? I
believe I was able to sort out the issue yesterday.

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/20190118/20eeb0ca/attachment.sig>

From ggreif at gmail.com  Sat Jan 19 10:47:36 2019
From: ggreif at gmail.com (Gabor Greif)
Date: Sat, 19 Jan 2019 11:47:36 +0100
Subject: Gitlab pain
In-Reply-To: <CAPKAvQUwso0_o=WvmCZU-BtWgap_VMiNxUEZROvCU_fz_38H+w@mail.gmail.com>
References: <AM0PR83MB0308A4CA4DCFFC1A8025E451AD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <EF6D110A-18B2-4D20-8F46-6F80BDF2DEBB@cs.brynmawr.edu>
 <CACbaDy5=DC67UxHCpZHhduHrn0L_fDxQWvN5DQ3qX0mmzXoZyQ@mail.gmail.com>
 <AM0PR83MB03087562CF878C3C2E220A7EAD8E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <87tvionvy2.fsf@smart-cactus.org>
 <CAKFCL4XeVP-wZ094t8fAUOhdKz8iDp5hnMh45tj6DHjKFn-LQQ@mail.gmail.com>
 <B637EC3A-702F-435F-AB07-B38804E8AB06@well-typed.com>
 <CAPKAvQUwso0_o=WvmCZU-BtWgap_VMiNxUEZROvCU_fz_38H+w@mail.gmail.com>
Message-ID: <CAK-hX0nLgVhikN_65aE4fW+NoARjBQEobXNy18MbXETT1bJuKA@mail.gmail.com>

I have just tried putting following URL into the discussion tab's URL bar

     javascript: $(".discussion-toggle-button:has(i.fa-chevron-down)").click()

and it seems to work.

Cheers,

    Gabor

On 1/4/19, Artem Pelenitsyn <a.pelenitsyn at gmail.com> wrote:
> It seems you'd want the "Toggle All" button. There is an issue for that:
>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/19149
>
> There is even a beautiful workaround given there with typing the following
> command in the JavaScript console in a browser:
> $(".discussion-toggle-button:has(i.fa-chevron-down)").click()
> After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
> module should reference the symbol") while before I could not.
>
> --
> Best, Artem
>
> On Fri, 4 Jan 2019 at 21:48 Ben Gamari <ben at well-typed.com> wrote:
>
>> Quite right. I will bring this up with upstream.
>>
>> On January 4, 2019 1:04:43 PM EST, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>>
>>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari <ben at smart-cactus.org> wrote:
>>>
>>>> As mentioned by others, discussions that have been marked as "resolved"
>>>> are collapsed by default. If you search for the text "Toggle
>>>> discussion"
>>>> you will find that the collapsed discussions have link on their
>>>> right-hand side which you can click on to expand the hidden comments.
>>>>
>>>
>>> The problem there being there's a lot of such, and no way to tell which
>>> one is relevant unless you have both original links and enough context.
>>> Finding stuff like that absent context doesn't look at all easy. :/
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allbery.b at gmail.com
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> 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  Sat Jan 19 20:55:06 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 19 Jan 2019 15:55:06 -0500
Subject: Thoughts on the Contributing page
Message-ID: <875zuke5az.fsf@smart-cactus.org>



For those following along at home:

   David has been looking at revising our contributor documentation.
   He has started consolidating a variety of relevant content on the
   Contributing page of the Wiki [1]. Below are my thoughts; feel free
   to chime in with your own.


David,

The contributing page is looking quite good. However, I do wonder
whether we could reduce the link "fan-out" a bit more: it still rather
feels like a collection of links with no clear "beginning".

The "Newcomers to GHC" section is a great start but I see two
potential issues:

 * we don't clearly articulate the precise steps that a newcomer will
   need to take

 * the first thing we mention are four links which, while useful,
   constitute a significant volume of reading for a newcomer.
   I fear we may lose people at this point.

Regarding the second point, I think that WorkingConventions/FixingBugs is a
good model in that it clearly lists a series of concrete steps that the
contributor should take. Admittedly, I think some of the detail should
be dropped or moved (e.g. the mention of setting git's user.name
variable is likely unnecessary in 2019).

I think that something similar to this list should be the first thing
one sees when they reach the contributing page. Ideally the "typical"
case of a new contributor wanting to submit their first patch would be
able to gather everything they need to get started in one or two
screenfuls of text. After that prose can come additional links to
more in-depth documentation.

Other various issues I noticed:

 * We link to wiki:WorkingConventions from a variety of places
   (including wiki:Contributing) but it is now just a link to
   wiki:Contributing.

 * wiki:WorkingConventions/FixingBugs still has references to
   Phabricator. In general we should start culling such references.

 * wiki:WorkingConventions/FixingBugs also has references to Trac
   documentation. We should try to replace these with the relevant
   GitLab documentation when we migrate.

 * wiki:WorkingConventions/FixingBugs should be updated to reflect
   that GitLab CI is now the source of truth for validation.

 * I don't know exactly how this should look but I think we need to do a
   better job of concisely stating what we expect of contributions. That
   is:

     * commit messages should be readable and discuss what the patch
       does. "Fixes #NNNN" is not an adequate commit message.

     * changes should be commented where necessary (my usual rule of
       thumb is "write the comment you would have liked to read when you
       started writing your patch"). We should mention the Note
       convention.

     * commit messages and comments should refer to ticket numbers where
       appropriate (e.g. using usual #NNNN syntax; people often get this
       wrong).

     * commits should be either squashed or logically distinct,
       individually buildable changes.

     * changes to most of `base` need to go through the CLC (this may be
       optional as defining what set of `base` this applies to is a bit
       tricky; in the interest of keeping things concise we may be
       better off handling this personally on a case-by-case basis)

     * code changes should conform to GHC's (somewhat fluid, for better
       or worse) code style
       (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)

     * thought should be given to testing

    Having a document which succinctly summarised these expectations as
    we could easily refer to it during code review. Even better, we
    could excerpt it as a checklist in our merge request description
    template (I have put up an initial attempt at this as !149).

Anyways, there is more to be said here but this email is getting a bit
long so let's leave it for future discussions.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Contributing
-------------- 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/20190119/16fba6f5/attachment.sig>

From ecrockett0 at gmail.com  Sun Jan 20 05:08:14 2019
From: ecrockett0 at gmail.com (Eric Crockett)
Date: Sat, 19 Jan 2019 21:08:14 -0800
Subject: Reproducing bugs without Stack
Message-ID: <CAApao_msCOH6KpO9KieAtgdySDuJ=hb_A1rLbGFBuyC3ZE-xOg@mail.gmail.com>

Devs,

I use Stack for all of my Haskell development. I recently ran into several
bugs, which I suspected to be GHC bugs. In the process of creating new
tickets, I noticed a banner reading "*Please try to provide reproduction
instructions which do not require "Stack"." *The request is reasonable to
help weed out bugs in Stack itself, but I could use some advice on how to
do that.

In particular, I'm having trouble reproducing bugs related to profiling.
For example, #16182 <https://ghc.haskell.org/trac/ghc/ticket/16182> is
about runtime crashes with the -hr profiling option. This was clearly a GHC
bug rather than a problem with stack, yet I have so far been unable to
produce the bug without Stack. Similarly, for #16166
<https://ghc.haskell.org/trac/ghc/ticket/16166>, I filed the ticket, then
after failing to reproduce the bug with cabal, assumed it must be a stack
bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in
fact a GHC bug. Ryan explained that my problem reproducing with cabal is
due to differences in the profiling options used by stack and cabal.

In summary, it would be helpful to have some instructions on how to take a
bug produced using Stack to one produced without. For example, if `stack
build [--profile] foo` produces a compile bug, how should I use cabal to
definitively determine if the bug is a problem with Stack or GHC?
Presumably it would begin with `cabal sandbox init`. Are there special
options to put in the cabal.config file so that cabal uses the same
profiling options as stack? Will those options be used when building all
dependencies?

Thanks,
Eric Crockett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190119/5d093aff/attachment.html>

From mgsloan at gmail.com  Sun Jan 20 06:26:53 2019
From: mgsloan at gmail.com (Michael Sloan)
Date: Sat, 19 Jan 2019 22:26:53 -0800
Subject: Reproducing bugs without Stack
In-Reply-To: <CAApao_msCOH6KpO9KieAtgdySDuJ=hb_A1rLbGFBuyC3ZE-xOg@mail.gmail.com>
References: <CAApao_msCOH6KpO9KieAtgdySDuJ=hb_A1rLbGFBuyC3ZE-xOg@mail.gmail.com>
Message-ID: <CAEDDsWdtP8JKizy5qHF_B=PEcwKrTdW3pCyk7LQWxW4LC_6TeA@mail.gmail.com>

I don't have a good answer to your overall question, particularly when
reproducing the issue necessarily requires a large set of build
dependencies.  However, one thing that may be helpful is to use `stack
build --cabal-verbose`.  This will pass `--verbose` when running
Setup.hs, and ghc invocations are included in its verbose output.

Assuming your terminal's current dir is the package that the ghc
invocation is building, and the dependencies are built, you can run
paste the ghc invocation after `stack exec -- ` and it should work.
So, for example:

```
stack exec -- /home/mgsloan/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc
--make -no-link -fbuilding-cabal-package ...
```

Then, perhaps you can try removing arguments of the ghc invocation to
attempt to arrive at a more minimal reproduction.

-Michael

On Sat, Jan 19, 2019 at 9:08 PM Eric Crockett <ecrockett0 at gmail.com> wrote:
>
> Devs,
>
> I use Stack for all of my Haskell development. I recently ran into several bugs, which I suspected to be GHC bugs. In the process of creating new tickets, I noticed a banner reading "Please try to provide reproduction instructions which do not require "Stack"." The request is reasonable to help weed out bugs in Stack itself, but I could use some advice on how to do that.
>
> In particular, I'm having trouble reproducing bugs related to profiling. For example, #16182 is about runtime crashes with the -hr profiling option. This was clearly a GHC bug rather than a problem with stack, yet I have so far been unable to produce the bug without Stack. Similarly, for #16166, I filed the ticket, then after failing to reproduce the bug with cabal, assumed it must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in fact a GHC bug. Ryan explained that my problem reproducing with cabal is due to differences in the profiling options used by stack and cabal.
>
> In summary, it would be helpful to have some instructions on how to take a bug produced using Stack to one produced without. For example, if `stack build [--profile] foo` produces a compile bug, how should I use cabal to definitively determine if the bug is a problem with Stack or GHC? Presumably it would begin with `cabal sandbox init`. Are there special options to put in the cabal.config file so that cabal uses the same profiling options as stack? Will those options be used when building all dependencies?
>
> Thanks,
> Eric Crockett
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From clintonmead at gmail.com  Mon Jan 21 05:59:14 2019
From: clintonmead at gmail.com (Clinton Mead)
Date: Mon, 21 Jan 2019 16:59:14 +1100
Subject: MR does not merge
In-Reply-To: <875zumezwf.fsf@smart-cactus.org>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736prgw2g.fsf@smart-cactus.org>
 <AM0PR83MB0308F47F0516B551B5D902C5AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <875zumezwf.fsf@smart-cactus.org>
Message-ID: <CAFDVgwGpqA7zLRiqqTrGO9d3ufeyG57MMa649yuL=xfsVafXMw@mail.gmail.com>

Hi All

I'm not a GHC dev so my understanding of this process is limited to this
thread but just my thoughts.

My understanding is that we want to achieve the following two goals:

1. Never allow code which breaks tests to be committed to master.
2. Ensure that master is up to date as soon as possible with recently
submitted merge requests (MR).

The issue seems to be that the only way to ensure 1 is to use a serial
"rebase/test/make master branch" process on every MR. Which means if you
get a lot of MRs in a row you can get a queue of MRs blowing out.

So what I propose is the following:

1. Keep a queue of pending MRs.
2. When the previous test is complete, create a branch (lets call it
"pending") which is all the MRs in the queue rebased firstly on master and
then each other. Drop any MRs which fail this rebasing.
3. Run tests against "pending"
4. If the tests pass, "pending" becomes "master". However, if the CI for
"pending" fails, "split" pending into two (half the MRs in each, perhaps
interleaving their size also), rebase them separately on master call them
"pending1" and "pending2". If there's only one MR pending, don't "split" it
(you can't), just report the test failure to the MR owner.
5. If either "pending1" or "pending2" passes, it becomes "master". Also,
whether either or both of "pending1" or "pending2" fails, go back to step 4
for these. If they both pass (which probably should never happen) maybe
just merge one into master arbitrarily and put the other MRs in the pending
MR queue.
6. Once we've merged all our MRs in to master (and perhaps through the
binary search above found the broken MR) start this process again with the
current pending MRs.

With this process we ensure master is never broken, but we can test and
merge n MRs in log(n) time, so the MR queue will not grow arbitrarily long
if the rate of submitted MRs exceeds the rate we run CI tests on them.

"Marge-bot" mentioned almost does what I suggest, except in the case of a
failure it runs the MRs one-by-one, instead of binary split like I suggest.
Perhaps my proposal could be best implemented as a patch to Marge-bot.


On Sat, Jan 19, 2019 at 2:42 AM Ben Gamari <ben at well-typed.com> wrote:

> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
>
> > |  Indeed this is a known issue that I have been working [1] with
> upstream
> > |  to resolve.
> >
> > Thanks. I'm not equipped to express a well-informed opinion about what
> > the best thing to do is. But in the meantime I WOULD be grateful for
> > explicit workflow advice. Specifically:
> >
> > * What steps should I take to get a patch committed to master,
> >   assuming I've done the review stuff and want to press "go"?
> >
> At the moment it's largely just a matter of when a bulk merge happens; I
> did a large merge on Wednesday and another yesterday.
>
> However, as Matthew suggested I think it may make sense to try using
> Marge bot to eliminate this manual process with little cost. It doesn't
> take particularly long to put together a bulk merge but it does require
> some form of human intervention which generally implies latency.
>
> 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/20190121/ea07f851/attachment.html>

From chak at justtesting.org  Mon Jan 21 17:12:07 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 21 Jan 2019 18:12:07 +0100
Subject: ANN: Multiple positions for GHC developers
Message-ID: <4E72E98B-74CA-4145-BE53-369AB3E7F525@justtesting.org>

Please excuse this non-technical message, but I assume this is interesting for the members of this list: 

  https://iohk.io/careers/#op-302245-ghc-web-backend-developer

(There are multiple positions, same spec.)

Cheers,
Manuel


From ben at well-typed.com  Mon Jan 21 21:06:30 2019
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 21 Jan 2019 16:06:30 -0500
Subject: MR does not merge
In-Reply-To: <CAFDVgwGpqA7zLRiqqTrGO9d3ufeyG57MMa649yuL=xfsVafXMw@mail.gmail.com>
References: <AM0PR83MB03080BA8468A411391450EE3AD820@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <8736prgw2g.fsf@smart-cactus.org>
 <AM0PR83MB0308F47F0516B551B5D902C5AD830@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <875zumezwf.fsf@smart-cactus.org>
 <CAFDVgwGpqA7zLRiqqTrGO9d3ufeyG57MMa649yuL=xfsVafXMw@mail.gmail.com>
Message-ID: <87sgxld8kv.fsf@smart-cactus.org>

Clinton Mead <clintonmead at gmail.com> writes:

> Hi All
>
> I'm not a GHC dev so my understanding of this process is limited to this
> thread but just my thoughts.
>
> My understanding is that we want to achieve the following two goals:
>
> 1. Never allow code which breaks tests to be committed to master.
> 2. Ensure that master is up to date as soon as possible with recently
> submitted merge requests (MR).
>
> The issue seems to be that the only way to ensure 1 is to use a serial
> "rebase/test/make master branch" process on every MR. Which means if you
> get a lot of MRs in a row you can get a queue of MRs blowing out.
>
> So what I propose is the following:
>
> 1. Keep a queue of pending MRs.
> 2. When the previous test is complete, create a branch (lets call it
> "pending") which is all the MRs in the queue rebased firstly on master and
> then each other. Drop any MRs which fail this rebasing.
> 3. Run tests against "pending"
> 4. If the tests pass, "pending" becomes "master". However, if the CI for
> "pending" fails, "split" pending into two (half the MRs in each, perhaps
> interleaving their size also), rebase them separately on master call them
> "pending1" and "pending2". If there's only one MR pending, don't "split" it
> (you can't), just report the test failure to the MR owner.
> 5. If either "pending1" or "pending2" passes, it becomes "master". Also,
> whether either or both of "pending1" or "pending2" fails, go back to step 4
> for these. If they both pass (which probably should never happen) maybe
> just merge one into master arbitrarily and put the other MRs in the pending
> MR queue.
> 6. Once we've merged all our MRs in to master (and perhaps through the
> binary search above found the broken MR) start this process again with the
> current pending MRs.
>
> With this process we ensure master is never broken, but we can test and
> merge n MRs in log(n) time, so the MR queue will not grow arbitrarily long
> if the rate of submitted MRs exceeds the rate we run CI tests on them.
>
> "Marge-bot" mentioned almost does what I suggest, except in the case of a
> failure it runs the MRs one-by-one, instead of binary split like I suggest.
> Perhaps my proposal could be best implemented as a patch to Marge-bot.
>
What you propose is similar to what upstream is planning [1]. While it
would be nice to have a better solution until this plan comes to
fruition, I'm personally a bit reluctant to put much effort into
marge-bot given that it really is just a stop-gap solution.

Of course, if someone else would like to pick up this project we would
be quite appreciative.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186
-------------- 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/20190121/e1a3eed7/attachment.sig>

From matthewtpickering at gmail.com  Tue Jan 22 14:49:25 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 22 Jan 2019 14:49:25 +0000
Subject: Drop into a nix shell with ghcHEAD
In-Reply-To: <CAD34_k+XO=xdFGKsHQN7kLAxpqDsjtksiqtY_879o=8eUUOQGw@mail.gmail.com>
References: <CALuQ0m-BHsxoGLFmir_qrdQ5aR1WZ6HjPCeZA3QNC1iOS6QnWw@mail.gmail.com>
 <CAD34_k+XO=xdFGKsHQN7kLAxpqDsjtksiqtY_879o=8eUUOQGw@mail.gmail.com>
Message-ID: <CALuQ0m8RvMJ3ZRbTYG7nhYpvN8VZVbzm2UkPX9du-AucTcHVww@mail.gmail.com>

I just extended it slightly so you can grab artifacts from MRs as
well. The interface is not perfect but should still be useful.

https://github.com/mpickering/ghc-artefact-nix

You can specify the two options `fork` and `branch` in order to download
an artefact for a contributors branch in order to test a merge request. For
example in order to test
[!180](https://gitlab.haskell.org/ghc/ghc/merge_requests/180) which
is on the fork called `brprice` and from branch `wip/doc-pragma-fixes`
I can run:

```
nix run -f https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
\
      --argstr fork brprice \
      --argstr branch wip/doc-pragma-fixes \
      ghcHEAD cabal-install
```

On Thu, Jan 17, 2019 at 3:49 AM chessai . <chessai1996 at gmail.com> wrote:
>
> Beautiful. Thanks for sharing
>
> On Wed, Jan 16, 2019 at 9:34 AM Matthew Pickering <matthewtpickering at gmail.com> wrote:
>>
>> Hi all,
>>
>> I have written a devastating new script which makes it easy to test
>> snippets and packages with build artefacts built by the gitlab CI. One
>> invocation of `nix-shell` will enter an environment with the most
>> recent build artefact from master.
>>
>> Usage:
>>
>> ```
>> > nix-shell https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
>> unpacking 'https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'...
>> <lots more output>
>> > ghc --version
>> The Glorious Glasgow Haskell Compilation System, version 8.7.20190115
>> ```
>>
>> Repo: https://github.com/mpickering/ghc-artefact-nix
>>
>> So far we have tested it works on NixOS and darwin but support for
>> other platforms that nix supports and we build artefacts for should be
>> easy. It might already work on i386 and aarch64 as well but I didn't
>> test these.
>>
>> Cheers,
>>
>> Matt
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From matthewtpickering at gmail.com  Tue Jan 22 18:07:29 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 22 Jan 2019 18:07:29 +0000
Subject: Drop into a nix shell with ghcHEAD
In-Reply-To: <CALuQ0m8RvMJ3ZRbTYG7nhYpvN8VZVbzm2UkPX9du-AucTcHVww@mail.gmail.com>
References: <CALuQ0m-BHsxoGLFmir_qrdQ5aR1WZ6HjPCeZA3QNC1iOS6QnWw@mail.gmail.com>
 <CAD34_k+XO=xdFGKsHQN7kLAxpqDsjtksiqtY_879o=8eUUOQGw@mail.gmail.com>
 <CALuQ0m8RvMJ3ZRbTYG7nhYpvN8VZVbzm2UkPX9du-AucTcHVww@mail.gmail.com>
Message-ID: <CALuQ0m-ZJ8w4-dr2pja52whj=R5mNOKuByBVaXsxRJWznaVA8w@mail.gmail.com>

I have now added a small wrapper script which allows you to pull
artefacts by MR number.

https://github.com/mpickering/ghc-artefact-nix#ghc-head-from-script

```
# Fetches MR 180
ghc-head-from 180
```

```
#Fetches ghc/master
ghc-head-from
```

The most convenient way to access the script is to add the attribute
`nur.repos.mpickering.ghc-head-from` to your configuration.nix.

Cheers,

Matt

On Tue, Jan 22, 2019 at 2:49 PM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> I just extended it slightly so you can grab artifacts from MRs as
> well. The interface is not perfect but should still be useful.
>
> https://github.com/mpickering/ghc-artefact-nix
>
> You can specify the two options `fork` and `branch` in order to download
> an artefact for a contributors branch in order to test a merge request. For
> example in order to test
> [!180](https://gitlab.haskell.org/ghc/ghc/merge_requests/180) which
> is on the fork called `brprice` and from branch `wip/doc-pragma-fixes`
> I can run:
>
> ```
> nix run -f https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
> \
>       --argstr fork brprice \
>       --argstr branch wip/doc-pragma-fixes \
>       ghcHEAD cabal-install
> ```
>
> On Thu, Jan 17, 2019 at 3:49 AM chessai . <chessai1996 at gmail.com> wrote:
> >
> > Beautiful. Thanks for sharing
> >
> > On Wed, Jan 16, 2019 at 9:34 AM Matthew Pickering <matthewtpickering at gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I have written a devastating new script which makes it easy to test
> >> snippets and packages with build artefacts built by the gitlab CI. One
> >> invocation of `nix-shell` will enter an environment with the most
> >> recent build artefact from master.
> >>
> >> Usage:
> >>
> >> ```
> >> > nix-shell https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
> >> unpacking 'https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'...
> >> <lots more output>
> >> > ghc --version
> >> The Glorious Glasgow Haskell Compilation System, version 8.7.20190115
> >> ```
> >>
> >> Repo: https://github.com/mpickering/ghc-artefact-nix
> >>
> >> So far we have tested it works on NixOS and darwin but support for
> >> other platforms that nix supports and we build artefacts for should be
> >> easy. It might already work on i386 and aarch64 as well but I didn't
> >> test these.
> >>
> >> Cheers,
> >>
> >> Matt
> >> _______________________________________________
> >> 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  Tue Jan 22 20:31:27 2019
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 22 Jan 2019 15:31:27 -0500
Subject: [GitLab] Introducing Marge-bot
Message-ID: <87k1iwbfja.fsf@smart-cactus.org>

Hi everyone,

As you might have noticed there is a new face on GitLab: Meet
@marge-bot.

Marge will be helping us with the pain of merging merge requests:
Currently the typical workflow to merge an accepted MR involves the
following:

 1. Rebase the MR on top of the current `master` branch
 2. Click on the "Merge when pipeline succeeds" button
 3. Wait.
 4. If another MR is merged before yours, return to step (1)

Given the volume of patches that we have, this process gets tiresome
quite quickly. Upstream knows [1] about this issue and is actively
working towards a solution which will likely be ready in a few months.

In the meantime, Marge automates this currently-manual process. With
Marge merging a patch involves just two steps:

 1. Ensure that the MR has at least one approval. This should happen in
    the course of normal review but ping @bgamari, @alpmestan, @osa1, or
    @tdammers if this was forgotten.

 2. Use the "Assignee" field in the sidebar on the right side of the MR
    to assign it to @marge-bot.

Once Marge notices your MR she will dutifully watch over it, rebasing it
as necessary until it is merged. If something goes awry, she will leave
a (hopefully) helpful message and assign the MR back to you.

So far Marge has been working out reasonably well and seems to be an
improvement over the status quo. However, she still has some quirks so
let me know if you think she is behaving erratically or otherwise have
questions.

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/20190122/6a6a3b4b/attachment.sig>

From ben at smart-cactus.org  Tue Jan 22 23:44:22 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 22 Jan 2019 18:44:22 -0500
Subject: Using same stdout/stderr files for multiple tests?
In-Reply-To: <CAMQQO3maZoYW6tdUfe_=OH4xmvdfhiN3xFpZaWk27YFCn24dxA@mail.gmail.com>
References: <CAMQQO3maZoYW6tdUfe_=OH4xmvdfhiN3xFpZaWk27YFCn24dxA@mail.gmail.com>
Message-ID: <87fttk9s18.fsf@smart-cactus.org>

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

> I have a test that I want to run with different compile and runtime parameters.
> I managed to reuse the source file across different tests by adding a
> extra_files(['source.hs']) to the tests, but I don't know how to do the same for
> stdout/stderr files. Any ideas?
>
> In more details, I have
>
>     test.hs
>     test.stdout
>
> and two tests
>
>     test('test',
>          [extra_run_opts('...')],
>          compile_and_run,
>          [])
>
>     test('test_debug',
>          [extra_run_opts('...'),
>           extra_hc_opts('-debug'),
>           extra_files(['test.hs'])],
>          compile_and_run,
>          [])
>
> The first test works fine, but the second test fails because I don't know how to
> tell it to use test.stdout as the stdout file and it looks for
> test_debug.stdout.
>
This is probably no longer relevant but:

I don't believe there is a way to do this. I would likely make
test_debug.stdout a symlink to test.stdout.

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/20190122/ddad386b/attachment.sig>

From omeragacan at gmail.com  Wed Jan 23 04:43:21 2019
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 23 Jan 2019 07:43:21 +0300
Subject: Using same stdout/stderr files for multiple tests?
In-Reply-To: <87fttk9s18.fsf@smart-cactus.org>
References: <CAMQQO3maZoYW6tdUfe_=OH4xmvdfhiN3xFpZaWk27YFCn24dxA@mail.gmail.com>
 <87fttk9s18.fsf@smart-cactus.org>
Message-ID: <CAMQQO3moG4vjnG_UXHzLbzW+kzSFBuZDi0JyFE9QMQfNXBBvQw@mail.gmail.com>

These days when I need something like this I just use a make rule, which is not
great as you have to run multiple tests in one make rule and you can't run only
one with the TESTS parameter or skip some of the tests.

Another problem is I can't have multiple tests that use single source file,
again I have to use a make rule.

Ömer

Ben Gamari <ben at smart-cactus.org>, 23 Oca 2019 Çar, 02:44 tarihinde şunu yazdı:
>
> Ömer Sinan Ağacan <omeragacan at gmail.com> writes:
>
> > I have a test that I want to run with different compile and runtime parameters.
> > I managed to reuse the source file across different tests by adding a
> > extra_files(['source.hs']) to the tests, but I don't know how to do the same for
> > stdout/stderr files. Any ideas?
> >
> > In more details, I have
> >
> >     test.hs
> >     test.stdout
> >
> > and two tests
> >
> >     test('test',
> >          [extra_run_opts('...')],
> >          compile_and_run,
> >          [])
> >
> >     test('test_debug',
> >          [extra_run_opts('...'),
> >           extra_hc_opts('-debug'),
> >           extra_files(['test.hs'])],
> >          compile_and_run,
> >          [])
> >
> > The first test works fine, but the second test fails because I don't know how to
> > tell it to use test.stdout as the stdout file and it looks for
> > test_debug.stdout.
> >
> This is probably no longer relevant but:
>
> I don't believe there is a way to do this. I would likely make
> test_debug.stdout a symlink to test.stdout.
>
> Cheers,
>
> - Ben

From tdammers at gmail.com  Wed Jan 23 08:47:13 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Wed, 23 Jan 2019 09:47:13 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <875zuke5az.fsf@smart-cactus.org>
References: <875zuke5az.fsf@smart-cactus.org>
Message-ID: <20190123084711.obgor2xoiwzjklul@nibbler>

On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> 
> 
> For those following along at home:
> 
>    David has been looking at revising our contributor documentation.
>    He has started consolidating a variety of relevant content on the
>    Contributing page of the Wiki [1]. Below are my thoughts; feel free
>    to chime in with your own.
> 
> 
> David,
> 
> The contributing page is looking quite good. However, I do wonder
> whether we could reduce the link "fan-out" a bit more: it still rather
> feels like a collection of links with no clear "beginning".

> 
> The "Newcomers to GHC" section is a great start but I see two
> potential issues:
> 
>  * we don't clearly articulate the precise steps that a newcomer will
>    need to take
> 
>  * the first thing we mention are four links which, while useful,
>    constitute a significant volume of reading for a newcomer.
>    I fear we may lose people at this point.

Agree; fan-out superficially seems like a good idea (more information is
good, right?), but it just ends up overwhelming and confusing people
here. More information can be linked to later; the "Newcomers' Guide"
should have a clear narrative, with highly opinionated, well-tested
steps that will lead you from "I have nothing" to "Baby's First Merge
Request" and essentially Just Work.

> Regarding the second point, I think that WorkingConventions/FixingBugs is a
> good model in that it clearly lists a series of concrete steps that the
> contributor should take. Admittedly, I think some of the detail should
> be dropped or moved (e.g. the mention of setting git's user.name
> variable is likely unnecessary in 2019).
> 
> I think that something similar to this list should be the first thing
> one sees when they reach the contributing page. Ideally the "typical"
> case of a new contributor wanting to submit their first patch would be
> able to gather everything they need to get started in one or two
> screenfuls of text. After that prose can come additional links to
> more in-depth documentation.

Exactly.

> 
> Other various issues I noticed:
> 
>  * We link to wiki:WorkingConventions from a variety of places
>    (including wiki:Contributing) but it is now just a link to
>    wiki:Contributing.

>  * wiki:WorkingConventions/FixingBugs still has references to
>    Phabricator. In general we should start culling such references.
> 
>  * wiki:WorkingConventions/FixingBugs also has references to Trac
>    documentation. We should try to replace these with the relevant
>    GitLab documentation when we migrate.
> 
>  * wiki:WorkingConventions/FixingBugs should be updated to reflect
>    that GitLab CI is now the source of truth for validation.

A good first step, I think, would be to simply grep the entire wiki for
terms like "phab", "trac", etc., which is going to be significantly
easier after the migration due to gitlab's wiki being a git repo of
markdown files, rather than SQL-backed. If we're pressed for man-hours,
it might even be best to just delete outdated pages, and evolve new
material as the need arises.

> 
>  * I don't know exactly how this should look but I think we need to do a
>    better job of concisely stating what we expect of contributions. That
>    is:
> 
>      * commit messages should be readable and discuss what the patch
>        does. "Fixes #NNNN" is not an adequate commit message.
> 
>      * changes should be commented where necessary (my usual rule of
>        thumb is "write the comment you would have liked to read when you
>        started writing your patch"). We should mention the Note
>        convention.
> 
>      * commit messages and comments should refer to ticket numbers where
>        appropriate (e.g. using usual #NNNN syntax; people often get this
>        wrong).
> 
>      * commits should be either squashed or logically distinct,
>        individually buildable changes.
> 
>      * changes to most of `base` need to go through the CLC (this may be
>        optional as defining what set of `base` this applies to is a bit
>        tricky; in the interest of keeping things concise we may be
>        better off handling this personally on a case-by-case basis)
> 
>      * code changes should conform to GHC's (somewhat fluid, for better
>        or worse) code style
>        (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)
> 
>      * thought should be given to testing
> 
>     Having a document which succinctly summarised these expectations as
>     we could easily refer to it during code review. Even better, we
>     could excerpt it as a checklist in our merge request description
>     template (I have put up an initial attempt at this as !149).

I believe this should be a separate, self-contained document; we should
not overload the New Contributors' Guide with this information, nor
should it be scattered across the rest of the documentation (though more
pages should exist to go into full detail on each of those points). The
New Contributors' Guide should, however, follow these practices and thus
document them by example. E.g., the tutorial should include a step where
you squash your commits and add suitable comments. Likewise, the NOTE:
convention can be introduced simply by walking through the steps as part
of the tutorial.

On a completely unrelated note, I was thinking that it may be feasible
and desirable to hack up a quick broken-links check for the wiki,
possibly even as part of the migration script (which has to extract wiki
links anyway as it goes, and also visits every wiki page at some point,
so maintaining a list of links and then crossing off the ones that exist
shouldn't be a huge effort). Armed with such a list, we could then
semi-automatically deal with broken links and redirects as part of a
cleanup sweep. I'll have to give redirects a bit more thought in this
context though.

From matthewtpickering at gmail.com  Wed Jan 23 09:28:44 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 23 Jan 2019 09:28:44 +0000
Subject: [GitLab] Introducing Marge-bot
In-Reply-To: <87k1iwbfja.fsf@smart-cactus.org>
References: <87k1iwbfja.fsf@smart-cactus.org>
Message-ID: <CALuQ0m9brzJ9SRR2jGONC+VfaV9PgezWA4Gez7noO05R7ZMCKw@mail.gmail.com>

It seems that in order for marge-bot to work best we need to
tighten up our policy towards merging so that it is only Marge
who performs the merges. I think Marge gets confused if people
push to master under her feet which means rebasing again and duplicating work.

Can we disable the "Merge when pipeline succeeds button" in order to
facilitate this?

I also don't think one should be allowed to approve their own
PR. If it is trivial enough to justify a self-accept then someone else
should also be able to trivially accept it.

Therefore I believe the correct workflow is:

1. Make a MR and assign it to someone if you want their specific review.
2. When the MR has been approved, the approver assigns the MR to marge.
3. Marge then performs the merge in her own time.

Cheers,

Matt

On Tue, Jan 22, 2019 at 8:31 PM Ben Gamari <ben at well-typed.com> wrote:
>
> Hi everyone,
>
> As you might have noticed there is a new face on GitLab: Meet
> @marge-bot.
>
> Marge will be helping us with the pain of merging merge requests:
> Currently the typical workflow to merge an accepted MR involves the
> following:
>
>  1. Rebase the MR on top of the current `master` branch
>  2. Click on the "Merge when pipeline succeeds" button
>  3. Wait.
>  4. If another MR is merged before yours, return to step (1)
>
> Given the volume of patches that we have, this process gets tiresome
> quite quickly. Upstream knows [1] about this issue and is actively
> working towards a solution which will likely be ready in a few months.
>
> In the meantime, Marge automates this currently-manual process. With
> Marge merging a patch involves just two steps:
>
>  1. Ensure that the MR has at least one approval. This should happen in
>     the course of normal review but ping @bgamari, @alpmestan, @osa1, or
>     @tdammers if this was forgotten.
>
>  2. Use the "Assignee" field in the sidebar on the right side of the MR
>     to assign it to @marge-bot.
>
> Once Marge notices your MR she will dutifully watch over it, rebasing it
> as necessary until it is merged. If something goes awry, she will leave
> a (hopefully) helpful message and assign the MR back to you.
>
> So far Marge has been working out reasonably well and seems to be an
> improvement over the status quo. However, she still has some quirks so
> let me know if you think she is behaving erratically or otherwise have
> questions.
>
> Cheers,
>
> - Ben
> _______________________________________________
> 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  Wed Jan 23 17:24:03 2019
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 23 Jan 2019 12:24:03 -0500
Subject: Disabled Travis
Message-ID: <87h8dz8ez3.fsf@smart-cactus.org>

Hi All,

Travis appears [1] to be both broken and struggling to keep up with our
builds. I have disabled it for now. If you have an interest in
maintaining Travis then feel free to fix and reenable it.

Cheers,

- Ben


[1] https://travis-ci.org/ghc/ghc/builds
-------------- 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/20190123/1cc4eddd/attachment.sig>

From ben at well-typed.com  Wed Jan 23 17:54:51 2019
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 23 Jan 2019 12:54:51 -0500
Subject: Thoughts on the Contributing page
In-Reply-To: <20190123084711.obgor2xoiwzjklul@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190123084711.obgor2xoiwzjklul@nibbler>
Message-ID: <87bm478dju.fsf@smart-cactus.org>

Tobias Dammers <tdammers at gmail.com> writes:

> On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
>> 
>> 
...
>
> I believe this should be a separate, self-contained document; we should
> not overload the New Contributors' Guide with this information, nor
> should it be scattered across the rest of the documentation (though more
> pages should exist to go into full detail on each of those points). The
> New Contributors' Guide should, however, follow these practices and thus
> document them by example. E.g., the tutorial should include a step where
> you squash your commits and add suitable comments. Likewise, the NOTE:
> convention can be introduced simply by walking through the steps as part
> of the tutorial.
>
Sounds like we are largely in agreement. Let's start on this after the
Trac migration is finished.

> On a completely unrelated note, I was thinking that it may be feasible
> and desirable to hack up a quick broken-links check for the wiki,
> possibly even as part of the migration script (which has to extract wiki
> links anyway as it goes, and also visits every wiki page at some point,
> so maintaining a list of links and then crossing off the ones that exist
> shouldn't be a huge effort). Armed with such a list, we could then
> semi-automatically deal with broken links and redirects as part of a
> cleanup sweep. I'll have to give redirects a bit more thought in this
> context though.

I was going to recommend we rather just use something off-the-shelf to
avoid reinventing the wheel. I use linkchecker [1] elsewhere and it
works quite well. I believe you can use its -W flag to catch
non-existent wiki pages (which won't return a 404).

Of course, if it's easier to do this as part of the migration script
then that is also fine.

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/20190123/05449571/attachment.sig>

From tdammers at gmail.com  Thu Jan 24 08:09:01 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Thu, 24 Jan 2019 09:09:01 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <87bm478dju.fsf@smart-cactus.org>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190123084711.obgor2xoiwzjklul@nibbler>
 <87bm478dju.fsf@smart-cactus.org>
Message-ID: <20190124080900.jyedu7nrfz7uwgvv@nibbler>

On Wed, Jan 23, 2019 at 12:54:51PM -0500, Ben Gamari wrote:
> >
> Sounds like we are largely in agreement. Let's start on this after the
> Trac migration is finished.

I can in fact start working on this already while the migration is
pipelined. It's just markdown in git, so writing a draft and then
merging it into the wiki is perfectly straightforward.

> I was going to recommend we rather just use something off-the-shelf to
> avoid reinventing the wheel. I use linkchecker [1] elsewhere and it
> works quite well. I believe you can use its -W flag to catch
> non-existent wiki pages (which won't return a 404).

Ofc, if we can do it without any extra coding effort, all the better.

I do think doing it as part of the migration script might make it easier
to capture those "redirect" pages (e.g.
https://ghc.haskell.org/trac/ghc/wiki/Newcomers): we're scraping anyway,
so I think detecting the shape of those pages shouldn't be overly
difficult, and might be something an off-the-shelf link checker isn't as
suitable for.

From simonpj at microsoft.com  Thu Jan 24 09:17:58 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Jan 2019 09:17:58 +0000
Subject: Groups and projects
Message-ID: <AM0PR83MB0308EFBD943D28495E2FD140AD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

> Alright, I believe I have found the issue: you are a member of 
> the GHC group and GitLab's default notification behavior is that 
> you will receive notifications for all events of repositories in 
> groups to which you belong.

OK thanks, that's helpful.

When you say "repository" could you also have said "project".  That is, are "projects" and "repositories" in 1-1 correspondence?

So, to understand the semantics, you can belong to

* A project.
* A group

What's the difference? The group seems to be "Glasgow Haskell Compiler"; the project seems to be "Glasgow Haskell Compiler / GHC".  Does that imply that 
 * every project is part of a group; but 
 * a group may have many projects?

Or maybe a project can be part of more than one group?

The "Custom settings" on a project seem to be identical to the "custom settings" for a group.  If Gitlab is deciding whether to send me a notification N, is it clear whether it's a "project notification" or a "group notification"?  If so, then it can consult the appropriate settings; but if not, it's not clear.

Sorry for all these questions.  It's astonishingly common for large software systems to describe the surface knobs without describing the underlying model that makes sense of all those knobs!


Simon


-----Original Message-----
From: Ben Gamari <ben at well-typed.com> 
Sent: 24 January 2019 03:30
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: GHC | hWaitForInput-accurate-pipe test (!21)

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Yes, tons of them! I attach a dozen that arrived in the last few hrs.
>
Alright, I believe I have found the issue: you are a member of the GHC group and GitLab's default notification behavior is that you will receive notifications for all events of repositories in groups to which you belong.

You can view and modify these settings yourself here but I have changed them to be a bit more selective. You should now only receive notifications of new merge requests and new comments on merge requests on which you have previously commented. Do let me know if you receive any more unwanted mail.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 497 bytes
Desc: signature.asc
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190124/7999e31f/attachment.sig>

From matthewtpickering at gmail.com  Thu Jan 24 11:46:32 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 24 Jan 2019 11:46:32 +0000
Subject: Why are nested brackets disallowed?
Message-ID: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>

There is a check in `RnSplice` which errors on the following program
with nested brackets.

```
prog = [| [| True |] |]

T.hs:4:11: error:
    • Template Haskell brackets cannot be nested (without intervening splices)
    • In the Template Haskell quotation [| True |]
      In the Template Haskell quotation [| [| True |] |]
  |
4 | prog = [| [| True |] |]
  |           ^^^^^^^^^^

```

As far as I can see the check was added in 2013 in this commit,
https://github.com/ghc/ghc/commit/d0d47ba76f8f0501cf3c4966bc83966ab38cac27#diff-58794f81a415f148d011de563988c2b5R170

But there is no note, no tests and no comment about why it was added.

I removed the check and added a `BracketE` constructor to the
template-haskell AST and the
code compiles fine.

I can also construct a program which needs to be spliced twice and
this also works fine.

```
func Add = [| (+) |]
func Mul = [| (*) |]

f1 "+" = [| Add |]
f1 "*" = [| Mul |]

comb s = [| func $(f1 s) |]
```
```
res = $($(comb "*"))
```

So it seems the restriction is quite arbitrary but I was wondering if
I was missing some limitation which meant this check was added. I
would not be surprised if something more complicated goes wrong with
splicing.

Cheers,

Matt

From ben at well-typed.com  Thu Jan 24 17:16:21 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 24 Jan 2019 12:16:21 -0500
Subject: Groups and projects
In-Reply-To: <AM0PR83MB0308EFBD943D28495E2FD140AD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0308EFBD943D28495E2FD140AD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <87pnsm6kny.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

>> Alright, I believe I have found the issue: you are a member of 
>> the GHC group and GitLab's default notification behavior is that 
>> you will receive notifications for all events of repositories in 
>> groups to which you belong.
>
> OK thanks, that's helpful.
>
> When you say "repository" could you also have said "project". That is,
> are "projects" and "repositories" in 1-1 correspondence?
>
Yes, exactly. A project has a git repository, a wiki, an issue tracker
(although this is currently disabled in the case of the ghc project),
and can accept pull requests. I have been guilty of using the words
"repository" and "project" interchangeably, which likely doesn't make
things any clearer.

> So, to understand the semantics, you can belong to
>
> * A project.
> * A group
>
> What's the difference? The group seems to be "Glasgow Haskell
> Compiler"; the project seems to be "Glasgow Haskell Compiler / GHC".
> Does that imply that
>
>  * every project is part of a group; but 
>  * a group may have many projects?
>
Almost. Projects have owners. An owner may be either a group or a user.
For instance,

 * https://gitlab.haskell.org/ghc/ghc is a project (named `ghc`)
   belonging to the `ghc` group.

 * https://gitlab.haskell.org/bgamari/ghc is a project belonging to the
   `bgamari` user.

Groups may nest. https://gitlab.haskell.org/ghc/packages is a subgroup
(named `packages`) of the `ghc` group.
https://gitlab.haskell.org/ghc/packages/haskeline is a project
(`haskeline`) owned by that group.

Users can be "members" of both groups and projects. There are a few
flavours of membership ("reporter", "developer", "maintainer", and
"owner") which all imply different sets of permissions (documented here
[1]). If a user is a member of a group then they are granted permissions
to all projects of that group (and its subgroups).

As you discovered, membership also implies a few things about the
notifications you will receive about a project or group of projects.


[1] https://docs.gitlab.com/ee/user/permissions.html

> Or maybe a project can be part of more than one group?
>
> The "Custom settings" on a project seem to be identical to the "custom
> settings" for a group. If Gitlab is deciding whether to send me a
> notification N, is it clear whether it's a "project notification" or a
> "group notification"? If so, then it can consult the appropriate
> settings; but if not, it's not clear.
>

> Sorry for all these questions. It's astonishingly common for large
> software systems to describe the surface knobs without describing the
> underlying model that makes sense of all those knobs!
>
Yes, this is quite true. I do hope I could help clear up the fog. Do ask
if things are still hazy.

Cheers,

- Ben

-------------- 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/20190124/9e011de1/attachment.sig>

From ben at smart-cactus.org  Thu Jan 24 17:42:25 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 24 Jan 2019 12:42:25 -0500
Subject: Why are nested brackets disallowed?
In-Reply-To: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
Message-ID: <87k1iu6jgh.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> There is a check in `RnSplice` which errors on the following program
> with nested brackets.
>
It might be good to explicitly include Geoff Mainland in this thread.
I'm not sure he'll see it otherwise.

Cheers,

- Ben

-------------- 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/20190124/d1beb027/attachment.sig>

From rae at cs.brynmawr.edu  Thu Jan 24 17:46:41 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 12:46:41 -0500
Subject: Why are nested brackets disallowed?
In-Reply-To: <87k1iu6jgh.fsf@smart-cactus.org>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
Message-ID: <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>

I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety.

I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile.

One question: how would staging work between nesting levels of brackets?

Richard

> On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Matthew Pickering <matthewtpickering at gmail.com> writes:
> 
>> There is a check in `RnSplice` which errors on the following program
>> with nested brackets.
>> 
> It might be good to explicitly include Geoff Mainland in this thread.
> I'm not sure he'll see it otherwise.
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From rae at cs.brynmawr.edu  Thu Jan 24 17:49:38 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 12:49:38 -0500
Subject: "resource exhausted" in CI
Message-ID: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>

Hi Ben,

The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:

  HC [stage 1] compiler/stage2/build/TcForeign.o
  HC [stage 1] compiler/stage2/build/TcRules.o
/tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device)
compiler/ghc.mk:445: recipe for target 'compiler/stage2/build/TcTyClsDecls.o' failed
make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Is there a way to avoid this? Or should I just restart the CI? And what does Marge think of it all? (As in, if I ask her to take another spin, will she do so on the same commit?)

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190124/e66c46fd/attachment.html>

From ben at smart-cactus.org  Thu Jan 24 18:21:26 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 24 Jan 2019 13:21:26 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
Message-ID: <87h8dx7w7z.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Hi Ben,
>
> The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:
>
>   HC [stage 1] compiler/stage2/build/TcForeign.o
>   HC [stage 1] compiler/stage2/build/TcRules.o
> /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device)
> compiler/ghc.mk:445: recipe for target 'compiler/stage2/build/TcTyClsDecls.o' failed
> make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> 
Wow, that was fast; I only configured this runner yesterday. I've
cleaned up the disk in question and will investigate the root cause. I
have also restarted all affected builds.

> Is there a way to avoid this? Or should I just restart the CI? And
> what does Marge think of it all? (As in, if I ask her to take another
> spin, will she do so on the same commit?)
>
I've restarted your job. The new job is [1]. If it passes Marge should
merge if she was so-instructed.

Cheers,

- Ben


[1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913
-------------- 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/20190124/e7013bce/attachment.sig>

From rae at cs.brynmawr.edu  Thu Jan 24 18:36:59 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 13:36:59 -0500
Subject: access failed CI artifacts
Message-ID: <92A5997B-41B0-4301-9650-1C2FDA835E81@cs.brynmawr.edu>

A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807

The failures are just some output changes. I could delicately use the log to extract the changes and commit them, but it would be better to have direct access to, say, the *.run.stderr files and then commit those. Is this possible? Note that I do not have a build of this tree locally, as it's the result of a rebase that affected the output. Of course, I could build locally, but it would be nice to skip that step.

Thanks!
Richard

From rae at cs.brynmawr.edu  Thu Jan 24 18:38:01 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 13:38:01 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <87h8dx7w7z.fsf@smart-cactus.org>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
Message-ID: <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>

Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got off the ground.

> On Jan 24, 2019, at 1:21 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> 
>> Hi Ben,
>> 
>> The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says:
>> 
>>  HC [stage 1] compiler/stage2/build/TcForeign.o
>>  HC [stage 1] compiler/stage2/build/TcRules.o
>> /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device)
>> compiler/ghc.mk:445: recipe for target 'compiler/stage2/build/TcTyClsDecls.o' failed
>> make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> 
> Wow, that was fast; I only configured this runner yesterday. I've
> cleaned up the disk in question and will investigate the root cause. I
> have also restarted all affected builds.
> 
>> Is there a way to avoid this? Or should I just restart the CI? And
>> what does Marge think of it all? (As in, if I ask her to take another
>> spin, will she do so on the same commit?)
>> 
> I've restarted your job. The new job is [1]. If it passes Marge should
> merge if she was so-instructed.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913


From ben at smart-cactus.org  Thu Jan 24 19:01:26 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 24 Jan 2019 14:01:26 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
 <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
Message-ID: <878sz97udb.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got off the ground.
>
It is possible that you pushed a rebase? This error generally means that
the commit is no longer accessible which may happen when you push a
rebase.

I believe I cited the job for the current version of the patch [1] in my
previous email. Note that the commit SHA is different between [1] and
the job you cited.

Cheers,

- Ben


[1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913
-------------- 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/20190124/bdc92fac/attachment.sig>

From ben at well-typed.com  Thu Jan 24 19:06:25 2019
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 24 Jan 2019 14:06:25 -0500
Subject: access failed CI artifacts
In-Reply-To: <92A5997B-41B0-4301-9650-1C2FDA835E81@cs.brynmawr.edu>
References: <92A5997B-41B0-4301-9650-1C2FDA835E81@cs.brynmawr.edu>
Message-ID: <875zud7u4x.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807
>
> The failures are just some output changes. I could delicately use the
> log to extract the changes and commit them, but it would be better to
> have direct access to, say, the *.run.stderr files and then commit
> those. Is this possible? Note that I do not have a build of this tree
> locally, as it's the result of a rebase that affected the output. Of
> course, I could build locally, but it would be nice to skip that step.
>
Unfortunately it's not possible to gain access to the resulting stderr
files; the working directory is blown up at the end of the build.

However, one thing I've been wanting to do for quite some time is to
teach the testsuite driver to report the actual test output in the JUnit
file it produces. With this you could in principle grab in the JUnit file
(which is one of the artifacts emitted by the job) and reliably scrape
the output from it.

Cheers,

- Ben
-------------- 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/20190124/a9efd71a/attachment.sig>

From rae at cs.brynmawr.edu  Thu Jan 24 19:22:17 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 14:22:17 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <878sz97udb.fsf@smart-cactus.org>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
 <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
 <878sz97udb.fsf@smart-cactus.org>
Message-ID: <1937CA5B-9CCE-43C1-8474-A8E77109556E@cs.brynmawr.edu>

Ah, yes -- I did push a rebase. OK: good to know that this is expected behavior after rebasing (makes sense).

Thanks,
Richard

> On Jan 24, 2019, at 2:01 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> 
>> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got off the ground.
>> 
> It is possible that you pushed a rebase? This error generally means that
> the commit is no longer accessible which may happen when you push a
> rebase.
> 
> I believe I cited the job for the current version of the patch [1] in my
> previous email. Note that the commit SHA is different between [1] and
> the job you cited.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913


From simonpj at microsoft.com  Thu Jan 24 22:42:54 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Jan 2019 22:42:54 +0000
Subject: "resource exhausted" in CI
In-Reply-To: <1937CA5B-9CCE-43C1-8474-A8E77109556E@cs.brynmawr.edu>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
 <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
 <878sz97udb.fsf@smart-cactus.org>
 <1937CA5B-9CCE-43C1-8474-A8E77109556E@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308C8106A6E446CCC0C444DAD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

| Ah, yes -- I did push a rebase. OK: good to know that this is expected
| behavior after rebasing (makes sense).

Does not make sense (yet) to me.

Can someone explain (and perhaps document) the workflow here?

Simon

| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
| Eisenberg
| Sent: 24 January 2019 19:22
| To: Ben Gamari <ben at smart-cactus.org>
| Cc: GHC developers <ghc-devs at haskell.org>
| Subject: Re: "resource exhausted" in CI
| 
| Ah, yes -- I did push a rebase. OK: good to know that this is expected
| behavior after rebasing (makes sense).
| 
| Thanks,
| Richard
| 
| > On Jan 24, 2019, at 2:01 PM, Ben Gamari <ben at smart-cactus.org> wrote:
| >
| > Richard Eisenberg <rae at cs.brynmawr.edu> writes:
| >
| >> Something is awry:
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
| skell.org%2Frae%2Fghc%2F-
| %2Fjobs%2F16908&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea23444
| 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
| 1260172&amp;sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D&amp;
| reserved=0 never got off the ground.
| >>
| > It is possible that you pushed a rebase? This error generally means that
| > the commit is no longer accessible which may happen when you push a
| > rebase.
| >
| > I believe I cited the job for the current version of the patch [1] in my
| > previous email. Note that the commit SHA is different between [1] and
| > the job you cited.
| >
| > Cheers,
| >
| > - Ben
| >
| >
| > [1]
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
| skell.org%2Frae%2Fghc%2F-
| %2Fjobs%2F16913&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea23444
| 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
| 1260172&amp;sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3D&amp;re
| served=0
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
| ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea234447c3d2808d68
| 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172&amp
| ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3D&amp;reserved=0

From allbery.b at gmail.com  Thu Jan 24 22:53:36 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 24 Jan 2019 17:53:36 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <AM0PR83MB0308C8106A6E446CCC0C444DAD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
 <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
 <878sz97udb.fsf@smart-cactus.org>
 <1937CA5B-9CCE-43C1-8474-A8E77109556E@cs.brynmawr.edu>
 <AM0PR83MB0308C8106A6E446CCC0C444DAD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAKFCL4Uk0YtNn4S-CNEHib9jnsYAKp1=8GSdQpMYOLUcVno3XA@mail.gmail.com>

Rebase is more or less stashing and removing all local commits, upgrading
the underlying branch to current, then re-applying the local commits. This
changes the commit hashes for any re-applied commit that lands on a change
to the underlying branch, meaning that old commit hashes can be invalid
afterward.

(This is also why force-pushing causes problems, since this is only visible
in a local tree *unless* force-pushed upstream, meaning now those
changed/deleted commits affect anyone else who has checked out that
upstream branch. The normal process of upstreaming commits can't expose
local changes like that, since it all goes upstream as a group and becomes
a permanent part of the branch's history. Unless someone force-pushes the
branch afterward, forcibly overwriting that history with a different one
and leaving anyoneelse who'd checked out the branch with dangling commits
that no longer exist.)

Here, CI is making a copy of someone's branch and testing each commit in
turn to ensure consistency between multiple branches that touch the same
code, whose commits may end up interleaved. If the branch is rebased or
force-pushed during that testing, intermediate commits may become invalid
as above and CI would need to start over with a new list of commits.

On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
> | behavior after rebasing (makes sense).
>
> Does not make sense (yet) to me.
>
> Can someone explain (and perhaps document) the workflow here?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
> | Eisenberg
> | Sent: 24 January 2019 19:22
> | To: Ben Gamari <ben at smart-cactus.org>
> | Cc: GHC developers <ghc-devs at haskell.org>
> | Subject: Re: "resource exhausted" in CI
> |
> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
> | behavior after rebasing (makes sense).
> |
> | Thanks,
> | Richard
> |
> | > On Jan 24, 2019, at 2:01 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> | >
> | > Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> | >
> | >> Something is awry:
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
> | skell.org%2Frae%2Fghc%2F-
> | %2Fjobs%2F16908&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea23444
> |
> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
> |
> 1260172&amp;sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D&amp;
> | reserved=0 never got off the ground.
> | >>
> | > It is possible that you pushed a rebase? This error generally means
> that
> | > the commit is no longer accessible which may happen when you push a
> | > rebase.
> | >
> | > I believe I cited the job for the current version of the patch [1] in
> my
> | > previous email. Note that the commit SHA is different between [1] and
> | > the job you cited.
> | >
> | > Cheers,
> | >
> | > - Ben
> | >
> | >
> | > [1]
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
> | skell.org%2Frae%2Fghc%2F-
> | %2Fjobs%2F16913&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea23444
> |
> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
> |
> 1260172&amp;sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3D&amp;re
> | served=0
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C375c6daea234447c3d2808d68
> |
> 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172&amp
> |
> ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%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/20190124/4ede702c/attachment.html>

From allbery.b at gmail.com  Thu Jan 24 23:03:06 2019
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 24 Jan 2019 18:03:06 -0500
Subject: "resource exhausted" in CI
In-Reply-To: <CAKFCL4Uk0YtNn4S-CNEHib9jnsYAKp1=8GSdQpMYOLUcVno3XA@mail.gmail.com>
References: <9A1C7C22-1DF2-494C-A371-1E0925251287@cs.brynmawr.edu>
 <87h8dx7w7z.fsf@smart-cactus.org>
 <F3907929-FC3D-4669-8AF8-AC246C77C329@cs.brynmawr.edu>
 <878sz97udb.fsf@smart-cactus.org>
 <1937CA5B-9CCE-43C1-8474-A8E77109556E@cs.brynmawr.edu>
 <AM0PR83MB0308C8106A6E446CCC0C444DAD9A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CAKFCL4Uk0YtNn4S-CNEHib9jnsYAKp1=8GSdQpMYOLUcVno3XA@mail.gmail.com>
Message-ID: <CAKFCL4WBC=DebhF3HOE9zCEXEZiOe4RKXewsiudTNcZrHWQ1Ww@mail.gmail.com>

Um, also this seems to have jumped threads; the subject of this message was
a different issue, about disk space. Is that part of the confusion?

On Thu, Jan 24, 2019 at 5:53 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> Rebase is more or less stashing and removing all local commits, upgrading
> the underlying branch to current, then re-applying the local commits. This
> changes the commit hashes for any re-applied commit that lands on a change
> to the underlying branch, meaning that old commit hashes can be invalid
> afterward.
>
> (This is also why force-pushing causes problems, since this is only
> visible in a local tree *unless* force-pushed upstream, meaning now those
> changed/deleted commits affect anyone else who has checked out that
> upstream branch. The normal process of upstreaming commits can't expose
> local changes like that, since it all goes upstream as a group and becomes
> a permanent part of the branch's history. Unless someone force-pushes the
> branch afterward, forcibly overwriting that history with a different one
> and leaving anyoneelse who'd checked out the branch with dangling commits
> that no longer exist.)
>
> Here, CI is making a copy of someone's branch and testing each commit in
> turn to ensure consistency between multiple branches that touch the same
> code, whose commits may end up interleaved. If the branch is rebased or
> force-pushed during that testing, intermediate commits may become invalid
> as above and CI would need to start over with a new list of commits.
>
> On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
>> | behavior after rebasing (makes sense).
>>
>> Does not make sense (yet) to me.
>>
>> Can someone explain (and perhaps document) the workflow here?
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
>> | Eisenberg
>> | Sent: 24 January 2019 19:22
>> | To: Ben Gamari <ben at smart-cactus.org>
>> | Cc: GHC developers <ghc-devs at haskell.org>
>> | Subject: Re: "resource exhausted" in CI
>> |
>> | Ah, yes -- I did push a rebase. OK: good to know that this is expected
>> | behavior after rebasing (makes sense).
>> |
>> | Thanks,
>> | Richard
>> |
>> | > On Jan 24, 2019, at 2:01 PM, Ben Gamari <ben at smart-cactus.org> wrote:
>> | >
>> | > Richard Eisenberg <rae at cs.brynmawr.edu> writes:
>> | >
>> | >> Something is awry:
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
>> | skell.org%2Frae%2Fghc%2F-
>> | %2Fjobs%2F16908&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea23444
>> |
>> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
>> |
>> 1260172&amp;sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D&amp;
>> | reserved=0 never got off the ground.
>> | >>
>> | > It is possible that you pushed a rebase? This error generally means
>> that
>> | > the commit is no longer accessible which may happen when you push a
>> | > rebase.
>> | >
>> | > I believe I cited the job for the current version of the patch [1] in
>> my
>> | > previous email. Note that the commit SHA is different between [1] and
>> | > the job you cited.
>> | >
>> | > Cheers,
>> | >
>> | > - Ben
>> | >
>> | >
>> | > [1]
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
>> | skell.org%2Frae%2Fghc%2F-
>> | %2Fjobs%2F16913&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea23444
>> |
>> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552
>> |
>> 1260172&amp;sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3D&amp;re
>> | served=0
>> |
>> | _______________________________________________
>> | ghc-devs mailing list
>> | ghc-devs at haskell.org
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
>> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>> | devs&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C375c6daea234447c3d2808d68
>> |
>> 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172&amp
>> |
>> ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%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
>


-- 
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/20190124/b8e7f1e8/attachment.html>

From andrey.mokhov at newcastle.ac.uk  Fri Jan 25 02:27:24 2019
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Fri, 25 Jan 2019 02:27:24 +0000
Subject: [ANNOUNCE] You should try Hadrian
References: <AM6PR0702MB354355D50465344CD741050AA59B0@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>

Dear GHC developers,

Summary: You should try to use Hadrian as the GHC build system, because it will (hopefully!) become the default around GHC 8.8.

What is Hadrian and how can I try it?
=====================================

Hadrian is a new build system for GHC written in Haskell. It lives in the directory "hadrian" in the GHC tree, and we have been actively developing it in the past year to reach feature and correctness parity with the existing Make-based build system. While we haven't quite reached this goal (more on this below), Hadrian is already working well and we run Hadrian jobs alongside the Make ones in our CI pipelines since the recent move to GitLab.

At this point, we would like to encourage everyone to try using Hadrian for their usual GHC development tasks. Hadrian's documentation resides in GHC's source tree, and below are the documents you will be most interested in:


*        https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md: The root of Hadrian's documentation. It explains the basics and points to more specific documents where appropriate.



*        https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md: A cheatsheet-style document for GHC developers used to the Make build system (that is, most/all of you), showing equivalent Make/Hadrian commands for many tasks.


*        https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md: A description of the "user settings" mechanism in Hadrian, which is where you can customise the build flavour, choose the packages to build, add file/package/platform-specific command line flags, etc.


*        https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md: A description of the "test" rule and all the options it supports.

The documentation can surely be improved, so please do not hesitate to send us feedback and suggestions here, or even better on Trac: make sure you choose the component "Build System (Hadrian)" when creating a new ticket.

You need Hadrian
================

Hadrian is new, requires time to learn, and still has rough edges, but it has been developed to make your lives better. Here are a few advantages of Hadrian over the Make-based build system:

1) Hadrian is more reliable.

Hadrian can capture build dependencies more accurately, which means you rarely (if ever) need to do a clean rebuild.

2) Hadrian is faster.

Hadrian is faster for two reasons: (i) more accurate build dependencies, (ii) tracking of file contents instead of file modification times. Both allow you to avoid a lot of unnecessary rebuilds. Building Hadrian itself may take a while but needs to be done only once.

3) Hadrian is easier to understand and modify.

You no longer need to deal with Make's global namespace of mutable string variables. Hadrian is written in the language you love; it has modules, types and pure functions.


If you come across a situation where Hadrian is worse than the Make build system in any of the above aspects, this is a bug and you should report it.

Helping Hadrian
===============

The best way to help is to try Hadrian, and let us know how it goes, what doesn't work, what's missing for you, what you think should be easier, and so on. Below is a list of known issues that we are in the process of fixing or that we will be tackling soon:


*        Stage 2 GHC should be dynamically linked most of the time, but it never is, currently. See https://ghc.haskell.org/trac/ghc/ticket/15837

*        There are about a dozen of failing tests in the GHC testsuite, some related to #15837.

*        Binary distributions haven't been thoroughly tested on many platforms (only some Linux flavours). There will definitely be some issues here. For example, the binary distribution rule currently fails on Windows: https://ghc.haskell.org/trac/ghc/ticket/16073.

*        There is no "validate" rule yet, only "test", but we have all the pieces to make this happen and it has a very high priority.

*        There are issues with building cross compilers: see https://ghc.haskell.org/trac/ghc/ticket/16051.

We are likely missing some features compared to the Make build system, but none of them should take a lot of time to implement at this point. If you spot one, let us know! We'll do our best to implement it (or help you do it) as soon as we can. It is useful to look at the existing Hadrian tickets before submitting new ones, to make sure that the issue or idea that you would like to talk about hasn't been brought up yet: https://ghc.haskell.org/trac/ghc/query?status=!closed&component=Build+System+(Hadrian).

Of course, we welcome your code contributions too! Several GHC developers have a good understanding of Hadrian codebase and will be able to help you. To find their names, have a look at the list of recent Hadrian commits: https://gitlab.haskell.org/ghc/ghc/commits/master/hadrian. As you can see, Hadrian is actively developed by many people, and we hope you will join too.

Cheers,
Andrey

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

From rae at cs.brynmawr.edu  Fri Jan 25 04:02:30 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 23:02:30 -0500
Subject: Hadrian questions
Message-ID: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>

As suggested, I'm trying out Hadrian. I have a few questions.

 - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian?

 - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary?

 - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.)

I'm sure I'll have more questions.

Thanks!
Richard

From rae at cs.brynmawr.edu  Fri Jan 25 04:06:53 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 24 Jan 2019 23:06:53 -0500
Subject: Hadrian questions
In-Reply-To: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>
References: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>
Message-ID: <98F695EA-BAD0-4BB4-89C4-20A741CDD2A2@cs.brynmawr.edu>

In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too.

Maybe I'm not really on the devel2 flavor?

> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> As suggested, I'm trying out Hadrian. I have a few questions.
> 
> - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian?
> 
> - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary?
> 
> - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.)
> 
> I'm sure I'll have more questions.
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From matthewtpickering at gmail.com  Fri Jan 25 08:22:18 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 25 Jan 2019 08:22:18 +0000
Subject: Hadrian questions
In-Reply-To: <98F695EA-BAD0-4BB4-89C4-20A741CDD2A2@cs.brynmawr.edu>
References: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>
 <98F695EA-BAD0-4BB4-89C4-20A741CDD2A2@cs.brynmawr.edu>
Message-ID: <CALuQ0m_qUaG_VtDaKAqE0gKOvpv9iK0MbA40RZRNTDdK0Ctfng@mail.gmail.com>

`make 2` should be somewhat equivalent to `./hadrian/build.sh
_build/stage1/bin/ghc` I think.

The problem is with the devel2 flavour itself. Tracked by
https://ghc.haskell.org/trac/ghc/ticket/16210

The `hadrian/build.sh` script uses `cabal new-build` so the
dependencies should be shared already when possible.

Cheers,

Matt

On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
> In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too.
>
> Maybe I'm not really on the devel2 flavor?
>
> > On Jan 24, 2019, at 11:02 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> >
> > As suggested, I'm trying out Hadrian. I have a few questions.
> >
> > - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian?
> >
> > - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary?
> >
> > - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.)
> >
> > I'm sure I'll have more questions.
> >
> > Thanks!
> > Richard
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs 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 alec.theriault at gmail.com  Fri Jan 25 08:31:39 2019
From: alec.theriault at gmail.com (Alec Theriault)
Date: Fri, 25 Jan 2019 00:31:39 -0800
Subject: Hadrian questions
In-Reply-To: <CALuQ0m_qUaG_VtDaKAqE0gKOvpv9iK0MbA40RZRNTDdK0Ctfng@mail.gmail.com>
References: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>
 <98F695EA-BAD0-4BB4-89C4-20A741CDD2A2@cs.brynmawr.edu>
 <CALuQ0m_qUaG_VtDaKAqE0gKOvpv9iK0MbA40RZRNTDdK0Ctfng@mail.gmail.com>
Message-ID: <08B7CBD9-D75C-4B8A-8406-759341C5D37F@gmail.com>

Worth noting that Hadrian additionally defines a set of so-called phony targets for packages and executables, so `./hadrian/build.sh --freeze1 build/stage1/bin/ghc` can also be expressed independently from your build root as `./hadrian/build.sh --freeze1 stage2:exe:ghc-bin`.

Alec 

> On Jan 25, 2019, at 12:22 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> `make 2` should be somewhat equivalent to `./hadrian/build.sh
> _build/stage1/bin/ghc` I think.
> 
> The problem is with the devel2 flavour itself. Tracked by
> https://ghc.haskell.org/trac/ghc/ticket/16210
> 
> The `hadrian/build.sh` script uses `cabal new-build` so the
> dependencies should be shared already when possible.
> 
> Cheers,
> 
> Matt
> 
> On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>> 
>> In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too.
>> 
>> Maybe I'm not really on the devel2 flavor?
>> 
>>> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>>> 
>>> As suggested, I'm trying out Hadrian. I have a few questions.
>>> 
>>> - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian?
>>> 
>>> - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary?
>>> 
>>> - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.)
>>> 
>>> I'm sure I'll have more questions.
>>> 
>>> Thanks!
>>> Richard
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs 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 matthewtpickering at gmail.com  Fri Jan 25 11:56:45 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 25 Jan 2019 11:56:45 +0000
Subject: Why are nested brackets disallowed?
In-Reply-To: <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
 <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
Message-ID: <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>

I don't think that cross stage persistence will work as it is
currently implemented which is probably why the check exists.

1. The normal case

foo x = [| x |] ===>
  foo x = [| $(lift x) |]

2. x is defined at stage 0, and used at stage 2.

One option is:
foo x = [| [| x |] |] ===>
  foo x = [| [| $($(lift (lift x))) |] |]
or
foo x = [| [| x |] |] ===>
  foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |]

We need to think a bit how to `lift` something of type `Q Exp` because
of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT
(I tested and this works after deriving 40 instances).

You can define `lift2` which lifts an expression twice as follows.

```
lift2 :: Lift a => a -> Q Exp
lift2 a = lift a >>= \e -> [| return $ $(lift e) |]
```

3. x is defined at stage 1 and used in stage 2

foo = [| \x -> [| x |] |] ===>
  foo = [| \x -> [| $(lift x) |] |]

Desugared with a single call to `lift` like normal.

4. x is defined in stage 2 and used in stage 1

foo = [| [| \x -> $(x) |] |]

Rejected just like usual. `x` won't be bound when the splice is run.

It seems that with some suitable care that things will work out when
lifting across multiple levels but that is the point where care needs
to be taken.

Matt



On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
> I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety.
>
> I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile.
>
> One question: how would staging work between nesting levels of brackets?
>
> Richard
>
> > On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> >
> > Matthew Pickering <matthewtpickering at gmail.com> writes:
> >
> >> There is a check in `RnSplice` which errors on the following program
> >> with nested brackets.
> >>
> > It might be good to explicitly include Geoff Mainland in this thread.
> > I'm not sure he'll see it otherwise.
> >
> > Cheers,
> >
> > - Ben
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Fri Jan 25 12:49:32 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 25 Jan 2019 12:49:32 +0000
Subject: Why are nested brackets disallowed?
In-Reply-To: <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
 <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
 <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
Message-ID: <AM0PR83MB0308335CAE44424F431ED3ADAD9B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Interesting. I don’t recall a specific reason why nested brackets were outlawed. I think it was just that we didn't think we needed them, so it seemed simplest not to have them.  TH does not do runtime codegen, so there are really only two stages: compile time and run time.

Do you have a compelling use-case?

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Matthew
|  Pickering
|  Sent: 25 January 2019 11:57
|  To: Richard Eisenberg <rae at cs.brynmawr.edu>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: Re: Why are nested brackets disallowed?
|  
|  I don't think that cross stage persistence will work as it is currently
|  implemented which is probably why the check exists.
|  
|  1. The normal case
|  
|  foo x = [| x |] ===>
|    foo x = [| $(lift x) |]
|  
|  2. x is defined at stage 0, and used at stage 2.
|  
|  One option is:
|  foo x = [| [| x |] |] ===>
|    foo x = [| [| $($(lift (lift x))) |] |] or foo x = [| [| x |] |] ===>
|    foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |]
|  
|  We need to think a bit how to `lift` something of type `Q Exp` because of
|  the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT (I
|  tested and this works after deriving 40 instances).
|  
|  You can define `lift2` which lifts an expression twice as follows.
|  
|  ```
|  lift2 :: Lift a => a -> Q Exp
|  lift2 a = lift a >>= \e -> [| return $ $(lift e) |] ```
|  
|  3. x is defined at stage 1 and used in stage 2
|  
|  foo = [| \x -> [| x |] |] ===>
|    foo = [| \x -> [| $(lift x) |] |]
|  
|  Desugared with a single call to `lift` like normal.
|  
|  4. x is defined in stage 2 and used in stage 1
|  
|  foo = [| [| \x -> $(x) |] |]
|  
|  Rejected just like usual. `x` won't be bound when the splice is run.
|  
|  It seems that with some suitable care that things will work out when
|  lifting across multiple levels but that is the point where care needs to
|  be taken.
|  
|  Matt
|  
|  
|  
|  On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg <rae at cs.brynmawr.edu>
|  wrote:
|  >
|  > I think Geoff was primarily concerned with typed Template Haskell, not
|  the untyped variety.
|  >
|  > I, too, have wondered if there was a technical reason behind this
|  restriction, or if merely it was assumed that nested brackets were not
|  worthwhile.
|  >
|  > One question: how would staging work between nesting levels of
|  brackets?
|  >
|  > Richard
|  >
|  > > On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org>
|  wrote:
|  > >
|  > > Matthew Pickering <matthewtpickering at gmail.com> writes:
|  > >
|  > >> There is a check in `RnSplice` which errors on the following
|  > >> program with nested brackets.
|  > >>
|  > > It might be good to explicitly include Geoff Mainland in this thread.
|  > > I'm not sure he'll see it otherwise.
|  > >
|  > > Cheers,
|  > >
|  > > - Ben
|  > >
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org
|  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
|  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
|  > > 7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d682bc3d4b%7C
|  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830&amp;sd
|  > > ata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&amp;reserved=0
|  >
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d
|  682bc3d4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830
|  &amp;sdata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&amp;reserved=
|  0

From rae at cs.brynmawr.edu  Fri Jan 25 12:50:39 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 25 Jan 2019 07:50:39 -0500
Subject: Why are nested brackets disallowed?
In-Reply-To: <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
 <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
 <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
Message-ID: <A55F5BB4-A7B6-4EC2-9851-0C7134F4F0F7@cs.brynmawr.edu>

This typechecks:

instance Lift a => Lift (Q a) where
  lift :: Q a -> Q Exp
  lift x = join (fmap lift x)

And it looks correct. Do you agree?

In general, it sounds like you've thought this through. To me, this doesn't rise to the need of a ghc-proposal; I would say to go for it.

Richard

> On Jan 25, 2019, at 6:56 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> I don't think that cross stage persistence will work as it is
> currently implemented which is probably why the check exists.
> 
> 1. The normal case
> 
> foo x = [| x |] ===>
>  foo x = [| $(lift x) |]
> 
> 2. x is defined at stage 0, and used at stage 2.
> 
> One option is:
> foo x = [| [| x |] |] ===>
>  foo x = [| [| $($(lift (lift x))) |] |]
> or
> foo x = [| [| x |] |] ===>
>  foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |]
> 
> We need to think a bit how to `lift` something of type `Q Exp` because
> of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT
> (I tested and this works after deriving 40 instances).
> 
> You can define `lift2` which lifts an expression twice as follows.
> 
> ```
> lift2 :: Lift a => a -> Q Exp
> lift2 a = lift a >>= \e -> [| return $ $(lift e) |]
> ```
> 
> 3. x is defined at stage 1 and used in stage 2
> 
> foo = [| \x -> [| x |] |] ===>
>  foo = [| \x -> [| $(lift x) |] |]
> 
> Desugared with a single call to `lift` like normal.
> 
> 4. x is defined in stage 2 and used in stage 1
> 
> foo = [| [| \x -> $(x) |] |]
> 
> Rejected just like usual. `x` won't be bound when the splice is run.
> 
> It seems that with some suitable care that things will work out when
> lifting across multiple levels but that is the point where care needs
> to be taken.
> 
> Matt
> 
> 
> 
> On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>> 
>> I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety.
>> 
>> I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile.
>> 
>> One question: how would staging work between nesting levels of brackets?
>> 
>> Richard
>> 
>>> On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org> wrote:
>>> 
>>> Matthew Pickering <matthewtpickering at gmail.com> writes:
>>> 
>>>> There is a check in `RnSplice` which errors on the following program
>>>> with nested brackets.
>>>> 
>>> It might be good to explicitly include Geoff Mainland in this thread.
>>> I'm not sure he'll see it otherwise.
>>> 
>>> Cheers,
>>> 
>>> - Ben
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 


From rae at cs.brynmawr.edu  Fri Jan 25 12:53:20 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 25 Jan 2019 07:53:20 -0500
Subject: Marge: "CI is taking too long"
Message-ID: <E2A7C338-84B1-4ECF-9FEE-C3E2AC3A643A@cs.brynmawr.edu>

Marge has complained that https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long. And indeed it seems stuck.

Help?

Thanks,
Richard

From matthewtpickering at gmail.com  Fri Jan 25 12:58:50 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 25 Jan 2019 12:58:50 +0000
Subject: Why are nested brackets disallowed?
In-Reply-To: <AM0PR83MB0308335CAE44424F431ED3ADAD9B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
 <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
 <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
 <AM0PR83MB0308335CAE44424F431ED3ADAD9B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m-+GvRz51aNwuK5fsz5iWM-AXkFPhVrgMXst+GcHA8qeg@mail.gmail.com>

It's possible to have multiple compile time phases (as evidenced by
the possibility of multiple splices). Metaocaml supports k phases so
we should as well!

Fwiw, It is also possible to implement run-time code generation, see

https://github.com/mainland/th-new
http://johnlato.blogspot.com/2012/10/runtime-meta-programming-in-haskell.html

On Fri, Jan 25, 2019 at 12:49 PM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> Interesting. I don’t recall a specific reason why nested brackets were outlawed. I think it was just that we didn't think we needed them, so it seemed simplest not to have them.  TH does not do runtime codegen, so there are really only two stages: compile time and run time.
>
> Do you have a compelling use-case?
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Matthew
> |  Pickering
> |  Sent: 25 January 2019 11:57
> |  To: Richard Eisenberg <rae at cs.brynmawr.edu>
> |  Cc: GHC developers <ghc-devs at haskell.org>
> |  Subject: Re: Why are nested brackets disallowed?
> |
> |  I don't think that cross stage persistence will work as it is currently
> |  implemented which is probably why the check exists.
> |
> |  1. The normal case
> |
> |  foo x = [| x |] ===>
> |    foo x = [| $(lift x) |]
> |
> |  2. x is defined at stage 0, and used at stage 2.
> |
> |  One option is:
> |  foo x = [| [| x |] |] ===>
> |    foo x = [| [| $($(lift (lift x))) |] |] or foo x = [| [| x |] |] ===>
> |    foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |]
> |
> |  We need to think a bit how to `lift` something of type `Q Exp` because of
> |  the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT (I
> |  tested and this works after deriving 40 instances).
> |
> |  You can define `lift2` which lifts an expression twice as follows.
> |
> |  ```
> |  lift2 :: Lift a => a -> Q Exp
> |  lift2 a = lift a >>= \e -> [| return $ $(lift e) |] ```
> |
> |  3. x is defined at stage 1 and used in stage 2
> |
> |  foo = [| \x -> [| x |] |] ===>
> |    foo = [| \x -> [| $(lift x) |] |]
> |
> |  Desugared with a single call to `lift` like normal.
> |
> |  4. x is defined in stage 2 and used in stage 1
> |
> |  foo = [| [| \x -> $(x) |] |]
> |
> |  Rejected just like usual. `x` won't be bound when the splice is run.
> |
> |  It seems that with some suitable care that things will work out when
> |  lifting across multiple levels but that is the point where care needs to
> |  be taken.
> |
> |  Matt
> |
> |
> |
> |  On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg <rae at cs.brynmawr.edu>
> |  wrote:
> |  >
> |  > I think Geoff was primarily concerned with typed Template Haskell, not
> |  the untyped variety.
> |  >
> |  > I, too, have wondered if there was a technical reason behind this
> |  restriction, or if merely it was assumed that nested brackets were not
> |  worthwhile.
> |  >
> |  > One question: how would staging work between nesting levels of
> |  brackets?
> |  >
> |  > Richard
> |  >
> |  > > On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org>
> |  wrote:
> |  > >
> |  > > Matthew Pickering <matthewtpickering at gmail.com> writes:
> |  > >
> |  > >> There is a check in `RnSplice` which errors on the following
> |  > >> program with nested brackets.
> |  > >>
> |  > > It might be good to explicitly include Geoff Mainland in this thread.
> |  > > I'm not sure he'll see it otherwise.
> |  > >
> |  > > Cheers,
> |  > >
> |  > > - Ben
> |  > >
> |  > > _______________________________________________
> |  > > ghc-devs mailing list
> |  > > ghc-devs at haskell.org
> |  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
> |  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
> |  > > 7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d682bc3d4b%7C
> |  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830&amp;sd
> |  > > ata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&amp;reserved=0
> |  >
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d
> |  682bc3d4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830
> |  &amp;sdata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&amp;reserved=
> |  0

From matthewtpickering at gmail.com  Fri Jan 25 12:59:49 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 25 Jan 2019 12:59:49 +0000
Subject: Why are nested brackets disallowed?
In-Reply-To: <A55F5BB4-A7B6-4EC2-9851-0C7134F4F0F7@cs.brynmawr.edu>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
 <87k1iu6jgh.fsf@smart-cactus.org>
 <B77EC8CD-6AA6-469A-AA33-8D03D9932903@cs.brynmawr.edu>
 <CALuQ0m_gsexZ4O1wMEib1GoAvzXuDFrFy7uvkxSVwACmwtxASQ@mail.gmail.com>
 <A55F5BB4-A7B6-4EC2-9851-0C7134F4F0F7@cs.brynmawr.edu>
Message-ID: <CALuQ0m_uCORd8U1-j5Nz1u3m9ngJtfCBj+5uZz_08g-=e9xPLg@mail.gmail.com>

That definition typechecks but doesn't do what you intend I think.

If you `lift (lift Bool)` then result of splicing this is of type
`Exp` and not `Q Exp` as you intended so you can't splice it again.

That is why my definition is more complicated and involves `return`.

Cheers,

Matt

On Fri, Jan 25, 2019 at 12:50 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
> This typechecks:
>
> instance Lift a => Lift (Q a) where
>   lift :: Q a -> Q Exp
>   lift x = join (fmap lift x)
>
> And it looks correct. Do you agree?
>
> In general, it sounds like you've thought this through. To me, this doesn't rise to the need of a ghc-proposal; I would say to go for it.
>
> Richard
>
> > On Jan 25, 2019, at 6:56 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> >
> > I don't think that cross stage persistence will work as it is
> > currently implemented which is probably why the check exists.
> >
> > 1. The normal case
> >
> > foo x = [| x |] ===>
> >  foo x = [| $(lift x) |]
> >
> > 2. x is defined at stage 0, and used at stage 2.
> >
> > One option is:
> > foo x = [| [| x |] |] ===>
> >  foo x = [| [| $($(lift (lift x))) |] |]
> > or
> > foo x = [| [| x |] |] ===>
> >  foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |]
> >
> > We need to think a bit how to `lift` something of type `Q Exp` because
> > of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT
> > (I tested and this works after deriving 40 instances).
> >
> > You can define `lift2` which lifts an expression twice as follows.
> >
> > ```
> > lift2 :: Lift a => a -> Q Exp
> > lift2 a = lift a >>= \e -> [| return $ $(lift e) |]
> > ```
> >
> > 3. x is defined at stage 1 and used in stage 2
> >
> > foo = [| \x -> [| x |] |] ===>
> >  foo = [| \x -> [| $(lift x) |] |]
> >
> > Desugared with a single call to `lift` like normal.
> >
> > 4. x is defined in stage 2 and used in stage 1
> >
> > foo = [| [| \x -> $(x) |] |]
> >
> > Rejected just like usual. `x` won't be bound when the splice is run.
> >
> > It seems that with some suitable care that things will work out when
> > lifting across multiple levels but that is the point where care needs
> > to be taken.
> >
> > Matt
> >
> >
> >
> > On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> >>
> >> I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety.
> >>
> >> I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile.
> >>
> >> One question: how would staging work between nesting levels of brackets?
> >>
> >> Richard
> >>
> >>> On Jan 24, 2019, at 12:42 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> >>>
> >>> Matthew Pickering <matthewtpickering at gmail.com> writes:
> >>>
> >>>> There is a check in `RnSplice` which errors on the following program
> >>>> with nested brackets.
> >>>>
> >>> It might be good to explicitly include Geoff Mainland in this thread.
> >>> I'm not sure he'll see it otherwise.
> >>>
> >>> Cheers,
> >>>
> >>> - Ben
> >>>
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
>

From ben at smart-cactus.org  Fri Jan 25 13:10:33 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 25 Jan 2019 08:10:33 -0500
Subject: Marge: "CI is taking too long"
In-Reply-To: <E2A7C338-84B1-4ECF-9FEE-C3E2AC3A643A@cs.brynmawr.edu>
References: <E2A7C338-84B1-4ECF-9FEE-C3E2AC3A643A@cs.brynmawr.edu>
Message-ID: <87woms6fy3.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Marge has complained that
> https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long.
> And indeed it seems stuck.
>
Indeed currently CI is a bit backed up. There are a few reasons for
this:

 * I am currently in the middle of a (now two-day-long) internet outage
   meaning a non-trivial fraction (roughly half) of our builder capacity
   is off-line. I have been reassured that service will be restored by 7
   PM today.

 * there has been a significant number of patches recently, especially
   since I have recently migrated a number of patches from Phabricator.

Consequently it doesn't surprise me that CI is taking a while.

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/20190125/20672cbe/attachment.sig>

From rae at cs.brynmawr.edu  Fri Jan 25 13:18:08 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 25 Jan 2019 08:18:08 -0500
Subject: Hadrian questions
In-Reply-To: <CALuQ0m_qUaG_VtDaKAqE0gKOvpv9iK0MbA40RZRNTDdK0Ctfng@mail.gmail.com>
References: <F8FE67BE-7DA7-4E54-B219-126A870CC8EC@cs.brynmawr.edu>
 <98F695EA-BAD0-4BB4-89C4-20A741CDD2A2@cs.brynmawr.edu>
 <CALuQ0m_qUaG_VtDaKAqE0gKOvpv9iK0MbA40RZRNTDdK0Ctfng@mail.gmail.com>
Message-ID: <06BD09CB-A9A9-414F-8733-85224E336AA7@cs.brynmawr.edu>

Maybe I'm just lazy, but would it be possible to shorten these? Specifically, could there be a root-level file `build` that triggers Hadrian? That way, I could just say ./build instead of hadrian/build.sh.

Actually, even that isn't quite right. It is common, for example, for me to be deep in the testsuite, trying to fix a test. I twiddle something (say, the output file), and then I want to rerun the test. But now I have to go back out to the root of my tree to run the test, no? So: I think it would be very convenient to make a script we can all install (in our PATH) that will search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only one who would enjoy it.

Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, and I don't see a way to run just one directory of the testsuite. I use that ability currently quite often (because I know that I've mucked with the typechecker, so I just run the typecheck tests before doing full CI). Is this possible?

Thanks for all the work on this!
Richard

> On Jan 25, 2019, at 3:22 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> `make 2` should be somewhat equivalent to `./hadrian/build.sh
> _build/stage1/bin/ghc` I think.
> 
> The problem is with the devel2 flavour itself. Tracked by
> https://ghc.haskell.org/trac/ghc/ticket/16210
> 
> The `hadrian/build.sh` script uses `cabal new-build` so the
> dependencies should be shared already when possible.
> 
> Cheers,
> 
> Matt
> 
> On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>> 
>> In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too.
>> 
>> Maybe I'm not really on the devel2 flavor?
>> 
>>> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>>> 
>>> As suggested, I'm trying out Hadrian. I have a few questions.
>>> 
>>> - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian?
>>> 
>>> - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary?
>>> 
>>> - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.)
>>> 
>>> I'm sure I'll have more questions.
>>> 
>>> Thanks!
>>> Richard
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs 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 klebinger.andreas at gmx.at  Fri Jan 25 13:28:17 2019
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Fri, 25 Jan 2019 14:28:17 +0100
Subject: Getting a profiled GHC with hadrian.
Message-ID: <5C4B0EF1.1000903@gmx.at>

Hello Devs,

What's the proper way to get a profiled GHC in hadrian?

I tried

   hadrian/build.cabal.sh -j8 --flavour=Prof

but that didn't work out:

   $ _build/stage1/bin/ghc.exe +RTS -p
   ghc.exe: the flag -p requires the program to be built with -prof
   ghc.exe:
   ...

What am I doing wrong here?

Cheers
Andreas

From alp at well-typed.com  Fri Jan 25 13:43:16 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Fri, 25 Jan 2019 14:43:16 +0100
Subject: Getting a profiled GHC with hadrian.
In-Reply-To: <5C4B0EF1.1000903@gmx.at>
References: <5C4B0EF1.1000903@gmx.at>
Message-ID: <a3f2e488-81af-dddf-a995-f7eb1d0ac609@well-typed.com>

Hello,

This is supposed to work, and worked for a while until some refactoring 
of mine which mistakenly dropped some logic. Matthew fixed it as soon as 
he noticed it though, so I suspect your branch doesn't have 
https://gitlab.haskell.org/ghc/ghc/commit/cfe64019a70acc1bae76f2fa580d6654f8eb5bc4 
? Cherry-picking this commit or rebasing against a quite recent master 
should fix the issue.

Sorry for the inconvenience.

On 25/01/2019 14:28, Andreas Klebinger wrote:
> Hello Devs,
>
> What's the proper way to get a profiled GHC in hadrian?
>
> I tried
>
>   hadrian/build.cabal.sh -j8 --flavour=Prof
>
> but that didn't work out:
>
>   $ _build/stage1/bin/ghc.exe +RTS -p
>   ghc.exe: the flag -p requires the program to be built with -prof
>   ghc.exe:
>   ...
>
> What am I doing wrong here?
>
> Cheers
> Andreas
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England


From lonetiger at gmail.com  Sat Jan 26 19:43:02 2019
From: lonetiger at gmail.com (Phyx)
Date: Sat, 26 Jan 2019 19:43:02 +0000
Subject: [GitLab] Introducing Marge-bot
In-Reply-To: <CALuQ0m9brzJ9SRR2jGONC+VfaV9PgezWA4Gez7noO05R7ZMCKw@mail.gmail.com>
References: <87k1iwbfja.fsf@smart-cactus.org>
 <CALuQ0m9brzJ9SRR2jGONC+VfaV9PgezWA4Gez7noO05R7ZMCKw@mail.gmail.com>
Message-ID: <CABHktDXzecW3z5KQL426829ExFEn--oMZs94mz30+itZmCc_dw@mail.gmail.com>

> I also don't think one should be allowed to approve their own
> PR. If it is trivial enough to justify a self-accept then someone else
> should also be able to trivially accept it.

I disagree whole heartedly, as someone who's had to wait weeks for trivial
patches to get reviews no thanks.
We should have a  formal definition of what is allowed to get committed as
trivial much like a lot of open source
projects do and go from there.

I prefer a practical workflow, not just one that works for areas of the
compiler where you have many people working,
It's a very frustrating experience otherwise.

Tamar.

On Wed, Jan 23, 2019 at 9:29 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> It seems that in order for marge-bot to work best we need to
> tighten up our policy towards merging so that it is only Marge
> who performs the merges. I think Marge gets confused if people
> push to master under her feet which means rebasing again and duplicating
> work.
>
> Can we disable the "Merge when pipeline succeeds button" in order to
> facilitate this?
>
> I also don't think one should be allowed to approve their own
> PR. If it is trivial enough to justify a self-accept then someone else
> should also be able to trivially accept it.
>
> Therefore I believe the correct workflow is:
>
> 1. Make a MR and assign it to someone if you want their specific review.
> 2. When the MR has been approved, the approver assigns the MR to marge.
> 3. Marge then performs the merge in her own time.
>
> Cheers,
>
> Matt
>
> On Tue, Jan 22, 2019 at 8:31 PM Ben Gamari <ben at well-typed.com> wrote:
> >
> > Hi everyone,
> >
> > As you might have noticed there is a new face on GitLab: Meet
> > @marge-bot.
> >
> > Marge will be helping us with the pain of merging merge requests:
> > Currently the typical workflow to merge an accepted MR involves the
> > following:
> >
> >  1. Rebase the MR on top of the current `master` branch
> >  2. Click on the "Merge when pipeline succeeds" button
> >  3. Wait.
> >  4. If another MR is merged before yours, return to step (1)
> >
> > Given the volume of patches that we have, this process gets tiresome
> > quite quickly. Upstream knows [1] about this issue and is actively
> > working towards a solution which will likely be ready in a few months.
> >
> > In the meantime, Marge automates this currently-manual process. With
> > Marge merging a patch involves just two steps:
> >
> >  1. Ensure that the MR has at least one approval. This should happen in
> >     the course of normal review but ping @bgamari, @alpmestan, @osa1, or
> >     @tdammers if this was forgotten.
> >
> >  2. Use the "Assignee" field in the sidebar on the right side of the MR
> >     to assign it to @marge-bot.
> >
> > Once Marge notices your MR she will dutifully watch over it, rebasing it
> > as necessary until it is merged. If something goes awry, she will leave
> > a (hopefully) helpful message and assign the MR back to you.
> >
> > So far Marge has been working out reasonably well and seems to be an
> > improvement over the status quo. However, she still has some quirks so
> > let me know if you think she is behaving erratically or otherwise have
> > questions.
> >
> > 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/20190126/1cdf15f0/attachment.html>

From ben at smart-cactus.org  Sat Jan 26 20:53:55 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 26 Jan 2019 15:53:55 -0500
Subject: [GitLab] Introducing Marge-bot
In-Reply-To: <CABHktDXzecW3z5KQL426829ExFEn--oMZs94mz30+itZmCc_dw@mail.gmail.com>
References: <87k1iwbfja.fsf@smart-cactus.org>
 <CALuQ0m9brzJ9SRR2jGONC+VfaV9PgezWA4Gez7noO05R7ZMCKw@mail.gmail.com>
 <CABHktDXzecW3z5KQL426829ExFEn--oMZs94mz30+itZmCc_dw@mail.gmail.com>
Message-ID: <87bm43dtsy.fsf@smart-cactus.org>

Phyx <lonetiger at gmail.com> writes:

>> I also don't think one should be allowed to approve their own
>> PR. If it is trivial enough to justify a self-accept then someone else
>> should also be able to trivially accept it.
>
> I disagree whole heartedly, as someone who's had to wait weeks for trivial
> patches to get reviews no thanks.
> We should have a  formal definition of what is allowed to get committed as
> trivial much like a lot of open source
> projects do and go from there.
>
> I prefer a practical workflow, not just one that works for areas of the
> compiler where you have many people working,
> It's a very frustrating experience otherwise.
>
I tend to agree. If someone has commit rights then I generally trust
their judgement when it comes to trivial patches. That being said, we
should indeed offer more guidance regarding what constitutes "trivial".

We currently have a lack of reviewers and I don't want this lack to
become a reason why those contributors we do have might be driven
away.

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/20190126/01fea1dd/attachment.sig>

From matthewtpickering at gmail.com  Sat Jan 26 21:04:43 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sat, 26 Jan 2019 21:04:43 +0000
Subject: Purpose of the CODEOWNERS file
Message-ID: <CALuQ0m9oghFTJ3sV5xuZ5NzQ218o=oCg67TMZxs16UWgBZ-Lhw@mail.gmail.com>

There have been a flurry of MRs to add ownership to the CODEOWNERS
file but it's not clear to me what this file does.

It links to this page: https://docs.gitlab.com/ee/user/project/code_owners.html

Which explains the syntax quite thoroughly but doesn't as far as I can
see explain how this information is used?

So before I add myself to some files, what does adding ownership actually do?

Cheers,

Matt

From ben at smart-cactus.org  Sat Jan 26 21:15:59 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 26 Jan 2019 16:15:59 -0500
Subject: Purpose of the CODEOWNERS file
In-Reply-To: <CALuQ0m9oghFTJ3sV5xuZ5NzQ218o=oCg67TMZxs16UWgBZ-Lhw@mail.gmail.com>
References: <CALuQ0m9oghFTJ3sV5xuZ5NzQ218o=oCg67TMZxs16UWgBZ-Lhw@mail.gmail.com>
Message-ID: <878sz7dss5.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> There have been a flurry of MRs to add ownership to the CODEOWNERS
> file but it's not clear to me what this file does.
>
> It links to this page: https://docs.gitlab.com/ee/user/project/code_owners.html
>
> Which explains the syntax quite thoroughly but doesn't as far as I can
> see explain how this information is used?
>
> So before I add myself to some files, what does adding ownership actually do?
>
When you open a merge request GitLab assigns a set of appropriate
reviewers. This set is determined by the owners of the files your merge
request touches [1].

Cheers,

- Ben


[1] https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#eligible-approvers
-------------- 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/20190126/da9dddb2/attachment.sig>

From rae at cs.brynmawr.edu  Sun Jan 27 14:56:01 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 27 Jan 2019 09:56:01 -0500
Subject: CI request: a DEBUG compiler
Message-ID: <FCAB04AD-42F9-4B56-AFFA-E736A1E6B5DA@cs.brynmawr.edu>

Hi devs,

I almost exclusively work with a DEBUG compiler. It continually shocks me that I'm relatively alone in this stance, as the ASSERTs littered throughout GHC have caught many a bug in easier a manner than long stares at -ddump-tc-trace would do. In any case, my goal in this email is not to convince you to follow suit. My goal is to request that our CI infrastructure include at least one testsuite run in a DEBUG compiler. A patch I'm working on is failing a test because of an assertion failure. I doubt my patch is the culprit, but I also can't categorically rule it out. So, I'm left rebuilding HEAD with DEBUG turned on to see if I can repro the ASSERTion failure. Clearly, having a CI trace of this would simplify things -- not to mention catch bugs earlier.

Thanks!
Richard

From ben at smart-cactus.org  Sun Jan 27 15:18:55 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 27 Jan 2019 10:18:55 -0500
Subject: CI request: a DEBUG compiler
In-Reply-To: <FCAB04AD-42F9-4B56-AFFA-E736A1E6B5DA@cs.brynmawr.edu>
References: <FCAB04AD-42F9-4B56-AFFA-E736A1E6B5DA@cs.brynmawr.edu>
Message-ID: <875zuadt7p.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Hi devs,
>
> I almost exclusively work with a DEBUG compiler. It continually shocks
> me that I'm relatively alone in this stance, as the ASSERTs littered
> throughout GHC have caught many a bug in easier a manner than long
> stares at -ddump-tc-trace would do. In any case, my goal in this email
> is not to convince you to follow suit. My goal is to request that our
> CI infrastructure include at least one testsuite run in a DEBUG
> compiler. A patch I'm working on is failing a test because of an
> assertion failure. I doubt my patch is the culprit, but I also can't
> categorically rule it out. So, I'm left rebuilding HEAD with DEBUG
> turned on to see if I can repro the ASSERTion failure. Clearly, having
> a CI trace of this would simplify things -- not to mention catch bugs
> earlier.
>
I completely agree; we do need to test DEBUG. I have an open merge
request (!58) which adds support for this but it currently fails (!) and
I haven't had time to look at sorting it out. I'll try to have a look today.

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/20190127/6a63f775/attachment.sig>

From ben at well-typed.com  Sun Jan 27 15:48:01 2019
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 27 Jan 2019 10:48:01 -0500
Subject: Profuse apologies for email spamming
Message-ID: <8736pedrvg.fsf@smart-cactus.org>

Hello everyone,

Just a moment ago mistakes were made during a test import of Trac
tickets. Consequently you may have found that you have received errant
email notifications from gitlab.staging.haskell.org. I have killed the
responsible job and ensured that this shouldn't happen again.

My apologies for any inconvenience this may have caused.

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/20190127/4150d8c7/attachment.sig>

From lonetiger at gmail.com  Sun Jan 27 16:36:39 2019
From: lonetiger at gmail.com (Phyx)
Date: Sun, 27 Jan 2019 16:36:39 +0000
Subject: Using same stdout/stderr files for multiple tests?
In-Reply-To: <CAMQQO3moG4vjnG_UXHzLbzW+kzSFBuZDi0JyFE9QMQfNXBBvQw@mail.gmail.com>
References: <CAMQQO3maZoYW6tdUfe_=OH4xmvdfhiN3xFpZaWk27YFCn24dxA@mail.gmail.com>
 <87fttk9s18.fsf@smart-cactus.org>
 <CAMQQO3moG4vjnG_UXHzLbzW+kzSFBuZDi0JyFE9QMQfNXBBvQw@mail.gmail.com>
Message-ID: <CABHktDVdFP7_5Yvx-5miqAXY7wopzkCiy1KXqN2-W4H=s6eUFw@mail.gmail.com>

Hi Omer,

If you frequently require this it would be a trivial thing to add, it's a
small modification to find_expected_file,
I can probably find some time next week to do this for you if you want.

>
> I don't believe there is a way to do this. I would likely make
> test_debug.stdout a symlink to test.stdout.

Please don't, the symlinks won't persist on Windows where we'll end up with
file copies instead, which goes horribly wrong once you modify one of them.

Regards,
Tamar

On Wed, Jan 23, 2019 at 4:44 AM Ömer Sinan Ağacan <omeragacan at gmail.com>
wrote:

> These days when I need something like this I just use a make rule, which
> is not
> great as you have to run multiple tests in one make rule and you can't run
> only
> one with the TESTS parameter or skip some of the tests.
>
> Another problem is I can't have multiple tests that use single source file,
> again I have to use a make rule.
>
> Ömer
>
> Ben Gamari <ben at smart-cactus.org>, 23 Oca 2019 Çar, 02:44 tarihinde şunu
> yazdı:
> >
> > Ömer Sinan Ağacan <omeragacan at gmail.com> writes:
> >
> > > I have a test that I want to run with different compile and runtime
> parameters.
> > > I managed to reuse the source file across different tests by adding a
> > > extra_files(['source.hs']) to the tests, but I don't know how to do
> the same for
> > > stdout/stderr files. Any ideas?
> > >
> > > In more details, I have
> > >
> > >     test.hs
> > >     test.stdout
> > >
> > > and two tests
> > >
> > >     test('test',
> > >          [extra_run_opts('...')],
> > >          compile_and_run,
> > >          [])
> > >
> > >     test('test_debug',
> > >          [extra_run_opts('...'),
> > >           extra_hc_opts('-debug'),
> > >           extra_files(['test.hs'])],
> > >          compile_and_run,
> > >          [])
> > >
> > > The first test works fine, but the second test fails because I don't
> know how to
> > > tell it to use test.stdout as the stdout file and it looks for
> > > test_debug.stdout.
> > >
> > This is probably no longer relevant but:
> >
> > I don't believe there is a way to do this. I would likely make
> > test_debug.stdout a symlink to test.stdout.
> >
> > 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/20190127/99da2cac/attachment.html>

From lonetiger at gmail.com  Sun Jan 27 20:24:35 2019
From: lonetiger at gmail.com (Phyx)
Date: Sun, 27 Jan 2019 20:24:35 +0000
Subject: Using same stdout/stderr files for multiple tests?
In-Reply-To: <CABHktDVdFP7_5Yvx-5miqAXY7wopzkCiy1KXqN2-W4H=s6eUFw@mail.gmail.com>
References: <CAMQQO3maZoYW6tdUfe_=OH4xmvdfhiN3xFpZaWk27YFCn24dxA@mail.gmail.com>
 <87fttk9s18.fsf@smart-cactus.org>
 <CAMQQO3moG4vjnG_UXHzLbzW+kzSFBuZDi0JyFE9QMQfNXBBvQw@mail.gmail.com>
 <CABHktDVdFP7_5Yvx-5miqAXY7wopzkCiy1KXqN2-W4H=s6eUFw@mail.gmail.com>
Message-ID: <CABHktDU7wAW38=Oi4DEMvF6mf3Cfjty-7oyZT1JGFe-Ww8Rzjw@mail.gmail.com>

Actually, I had a few minutes to spare on the train so
https://gitlab.haskell.org/ghc/ghc/merge_requests/226 :)

Cheers,
Tamar

On Sun, Jan 27, 2019 at 4:36 PM Phyx <lonetiger at gmail.com> wrote:

> Hi Omer,
>
> If you frequently require this it would be a trivial thing to add, it's a
> small modification to find_expected_file,
> I can probably find some time next week to do this for you if you want.
>
> >
> > I don't believe there is a way to do this. I would likely make
> > test_debug.stdout a symlink to test.stdout.
>
> Please don't, the symlinks won't persist on Windows where we'll end up
> with file copies instead, which goes horribly wrong once you modify one of
> them.
>
> Regards,
> Tamar
>
> On Wed, Jan 23, 2019 at 4:44 AM Ömer Sinan Ağacan <omeragacan at gmail.com>
> wrote:
>
>> These days when I need something like this I just use a make rule, which
>> is not
>> great as you have to run multiple tests in one make rule and you can't
>> run only
>> one with the TESTS parameter or skip some of the tests.
>>
>> Another problem is I can't have multiple tests that use single source
>> file,
>> again I have to use a make rule.
>>
>> Ömer
>>
>> Ben Gamari <ben at smart-cactus.org>, 23 Oca 2019 Çar, 02:44 tarihinde şunu
>> yazdı:
>> >
>> > Ömer Sinan Ağacan <omeragacan at gmail.com> writes:
>> >
>> > > I have a test that I want to run with different compile and runtime
>> parameters.
>> > > I managed to reuse the source file across different tests by adding a
>> > > extra_files(['source.hs']) to the tests, but I don't know how to do
>> the same for
>> > > stdout/stderr files. Any ideas?
>> > >
>> > > In more details, I have
>> > >
>> > >     test.hs
>> > >     test.stdout
>> > >
>> > > and two tests
>> > >
>> > >     test('test',
>> > >          [extra_run_opts('...')],
>> > >          compile_and_run,
>> > >          [])
>> > >
>> > >     test('test_debug',
>> > >          [extra_run_opts('...'),
>> > >           extra_hc_opts('-debug'),
>> > >           extra_files(['test.hs'])],
>> > >          compile_and_run,
>> > >          [])
>> > >
>> > > The first test works fine, but the second test fails because I don't
>> know how to
>> > > tell it to use test.stdout as the stdout file and it looks for
>> > > test_debug.stdout.
>> > >
>> > This is probably no longer relevant but:
>> >
>> > I don't believe there is a way to do this. I would likely make
>> > test_debug.stdout a symlink to test.stdout.
>> >
>> > 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/20190127/27a2473f/attachment.html>

From lonetiger at gmail.com  Sun Jan 27 21:10:36 2019
From: lonetiger at gmail.com (Phyx)
Date: Sun, 27 Jan 2019 21:10:36 +0000
Subject: [ANNOUNCE] You should try Hadrian
In-Reply-To: <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>
References: <AM6PR0702MB354355D50465344CD741050AA59B0@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>
Message-ID: <CABHktDXMbpcpeQP9devqVpfvtNXQ-7U5HCJvTBoNdCCr_RYTJw@mail.gmail.com>

Hi Andrey,

I'm looking at
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md
wondering why the default instructions for Windows are using stack, this
isn't currently the case.

In order for ./boot and configure to work already you need to be in an
msys2 environment. So having stack install its own, un-updated msys2 is not
a workflow I would recommend.

There's a dubious claim there that using stack is "more robust", what is
this claim based on?
I'm just confused when it was decided to switch the defaults, and why,
without any consultation.

Regards,
Tamar

On Fri, Jan 25, 2019 at 2:27 AM Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>
wrote:

> Dear GHC developers,
>
>
>
> Summary: You should try to use Hadrian as the GHC build system, because it
> will (hopefully!) become the default around GHC 8.8.
>
>
>
> What is Hadrian and how can I try it?
>
> =====================================
>
>
>
> Hadrian is a new build system for GHC written in Haskell. It lives in the
> directory “hadrian” in the GHC tree, and we have been actively developing
> it in the past year to reach feature and correctness parity with the
> existing Make-based build system. While we haven't quite reached this goal
> (more on this below), Hadrian is already working well and we run Hadrian
> jobs alongside the Make ones in our CI pipelines since the recent move to
> GitLab.
>
>
>
> At this point, we would like to encourage everyone to try using Hadrian
> for their usual GHC development tasks. Hadrian's documentation resides in
> GHC's source tree, and below are the documents you will be most interested
> in:
>
>
>
> ·        https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md:
> The root of Hadrian's documentation. It explains the basics and points to
> more specific documents where appropriate.
>
>
>
> ·
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md: A
> cheatsheet-style document for GHC developers used to the Make build system
> (that is, most/all of you), showing equivalent Make/Hadrian commands for
> many tasks.
>
>
>
> ·
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md:
> A description of the “user settings” mechanism in Hadrian, which is where
> you can customise the build flavour, choose the packages to build, add
> file/package/platform-specific command line flags, etc.
>
>
>
> ·
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md:
> A description of the “test” rule and all the options it supports.
>
>
>
> The documentation can surely be improved, so please do not hesitate to
> send us feedback and suggestions here, or even better on Trac: make sure
> you choose the component "Build System (Hadrian)" when creating a new
> ticket.
>
>
>
> You need Hadrian
>
> ================
>
>
>
> Hadrian is new, requires time to learn, and still has rough edges, but it
> has been developed to make your lives better. Here are a few advantages of
> Hadrian over the Make-based build system:
>
>
>
> 1) Hadrian is more reliable.
>
>
>
> Hadrian can capture build dependencies more accurately, which means you
> rarely (if ever) need to do a clean rebuild.
>
>
>
> 2) Hadrian is faster.
>
>
>
> Hadrian is faster for two reasons: (i) more accurate build dependencies,
> (ii) tracking of file contents instead of file modification times. Both
> allow you to avoid a lot of unnecessary rebuilds. Building Hadrian itself
> may take a while but needs to be done only once.
>
>
>
> 3) Hadrian is easier to understand and modify.
>
>
>
> You no longer need to deal with Make's global namespace of mutable string
> variables. Hadrian is written in the language you love; it has modules,
> types and pure functions.
>
>
>
>
>
> If you come across a situation where Hadrian is worse than the Make build
> system in any of the above aspects, this is a bug and you should report it.
>
>
>
> Helping Hadrian
>
> ===============
>
>
>
> The best way to help is to try Hadrian, and let us know how it goes, what
> doesn't work, what's missing for you, what you think should be easier, and
> so on. Below is a list of known issues that we are in the process of fixing
> or that we will be tackling soon:
>
>
>
> ·        Stage 2 GHC should be dynamically linked most of the time, but
> it never is, currently. See https://ghc.haskell.org/trac/ghc/ticket/15837
>
> ·        There are about a dozen of failing tests in the GHC testsuite,
> some related to #15837.
>
> ·        Binary distributions haven't been thoroughly tested on many
> platforms (only some Linux flavours). There will definitely be some issues
> here. For example, the binary distribution rule currently fails on Windows:
> https://ghc.haskell.org/trac/ghc/ticket/16073.
>
> ·        There is no “validate” rule yet, only “test”, but we have all
> the pieces to make this happen and it has a very high priority.
>
> ·        There are issues with building cross compilers: see
> https://ghc.haskell.org/trac/ghc/ticket/16051.
>
>
>
> We are likely missing some features compared to the Make build system, but
> none of them should take a lot of time to implement at this point. If you
> spot one, let us know! We'll do our best to implement it (or help you do
> it) as soon as we can. It is useful to look at the existing Hadrian tickets
> before submitting new ones, to make sure that the issue or idea that you
> would like to talk about hasn't been brought up yet:
> https://ghc.haskell.org/trac/ghc/query?status=!closed&component=Build+System+(Hadrian)
> .
>
>
>
> Of course, we welcome your code contributions too! Several GHC developers
> have a good understanding of Hadrian codebase and will be able to help you.
> To find their names, have a look at the list of recent Hadrian commits:
> https://gitlab.haskell.org/ghc/ghc/commits/master/hadrian. As you can
> see, Hadrian is actively developed by many people, and we hope you will
> join too.
>
>
>
> Cheers,
>
> Andrey
>
>
> _______________________________________________
> 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/20190127/2b1a9153/attachment.html>

From mail at joachim-breitner.de  Sun Jan 27 21:19:59 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 27 Jan 2019 22:19:59 +0100
Subject: CI request: a DEBUG compiler
In-Reply-To: <FCAB04AD-42F9-4B56-AFFA-E736A1E6B5DA@cs.brynmawr.edu>
References: <FCAB04AD-42F9-4B56-AFFA-E736A1E6B5DA@cs.brynmawr.edu>
Message-ID: <39f30c6ae250d45b6c090681cd4c0222379a77c3.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 27.01.2019, 09:56 -0500 schrieb Richard Eisenberg:
> Clearly, having a CI trace of this would simplify things -- not to
> mention catch bugs earlier.

absolutely agree, and I can’t help but notice that our first CI setup
on travis that I created four years ago had a DEBUG build right from
the start.

(And back then I also noticed that not many developers seem to be using
a DEBUG build…)

Cheers,
Joachim
-- 
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/20190127/2debafbd/attachment.sig>

From andrey.mokhov at newcastle.ac.uk  Sun Jan 27 22:49:29 2019
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Sun, 27 Jan 2019 22:49:29 +0000
Subject: [ANNOUNCE] You should try Hadrian
In-Reply-To: <WM!bc843d34dac517516bd51882042ac67558d201471b519f7dabd03788e41db2d6c10420367fbfba5befdca844d353b442!@mailhub-mx5.ncl.ac.uk>
References: <AM6PR0702MB354355D50465344CD741050AA59B0@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>
 <CABHktDXMbpcpeQP9devqVpfvtNXQ-7U5HCJvTBoNdCCr_RYTJw@mail.gmail.com>
 <WM!bc843d34dac517516bd51882042ac67558d201471b519f7dabd03788e41db2d6c10420367fbfba5befdca844d353b442!@mailhub-mx5.ncl.ac.uk>
 <AM6PR0702MB3543F25FB4BA955204D0D06DA5950@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!ef52cdf3bcb17ddf070ef0a09062a4d8ec17e83e19b56164fc9463ae352c0512d1e2a5d2fe049d450f06cf5de601a2c2!@mailhub-mx2.ncl.ac.uk>

Hi Tamar,

Here is the relevant bullet point from the README:

> On Windows, if you do not want to install MSYS, you can
> use the Stack-based build script (Stack provides a managed
> MSYS environment), as described in these instructions.
> If you don't mind installing MSYS yourself or already have it,
> you can use the Cabal-based build script.

As you can see, `doc/windows.md` is recommended for people who “do not want to install MSYS”. Perhaps, the wording is not clear enough – please feel free to suggest improvements.

> In order for ./boot and configure to work already you need to
> be in an msys2 environment.

Yes, and Stack provides it. This means, if you follow instructions in this file, you don’t need to install MSYS yourself.

> There's a dubious claim there that using stack is
> "more robust", what is this claim based on?

This claim is based on my experience. Installing the MSYS environment has never worked out smoothly for me. Doing this via Stack was indeed more robust (especially, when struggling with building GHC on Windows CI!). Has this been different in your experience?

> I'm just confused when it was decided to switch the defaults,
> and why, without any consultation.

I’m not sure what you mean. Could you clarify? The file `doc/windows.md` is 3 years old and hasn’t changed much since creation. The default build script `build.bat` currently uses Cabal:

```
rem By default on Windows we build Hadrian using Cabal
hadrian/build.cabal.bat %*
```

P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when moving to GitLab, and created this MR to fix this:

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

Please jump into the comments there if you’d like me to fix/clarify anything.

Thanks for reaching out!

Cheers,
Andrey

From: Phyx [mailto:lonetiger at gmail.com]
Sent: 27 January 2019 21:11
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Ben Gamari <ben at well-typed.com>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: [ANNOUNCE] You should try Hadrian

Hi Andrey,

I'm looking at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md
wondering why the default instructions for Windows are using stack, this isn't currently the case.

In order for ./boot and configure to work already you need to be in an msys2 environment. So having stack install its own, un-updated msys2 is not a workflow I would recommend.

There's a dubious claim there that using stack is "more robust", what is this claim based on?
I'm just confused when it was decided to switch the defaults, and why, without any consultation.

Regards,
Tamar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190127/a1575d39/attachment.html>

From andrey.mokhov at newcastle.ac.uk  Sun Jan 27 23:15:18 2019
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Sun, 27 Jan 2019 23:15:18 +0000
Subject: Hadrian questions
References: <AM6PR0702MB3543EA8929ED0FB8D95DF4DBA5950@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!51a5a5b9e2f54775dd324b91c89b1050e1dbbbbd21e9aaa21fa3091e12e8ce0d8edd37453ba7e2952cc1e38120701f0f!@mailhub-mx5.ncl.ac.uk>

Hi Richard,

First of all, thank you trying Hadrian and generating several new bug reports. This is very helpful!

> I think it would be very convenient to make a script we can all install (in our PATH) that will
> search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name
> the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only
> one who would enjoy it.

This sounds like a good feature request to me. Could you please add it on Trac, so it's not lost?

> Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md,
> and I don't see a way to run just one directory of the testsuite. I use that ability currently quite
> often (because I know that I've mucked with the typechecker, so I just run the typecheck tests 
> before doing full CI). Is this possible?

Yes, this should be possible. I believe Alp is currently working on the testsuite with the goal of fully matching the functionality provided by the Make build system. I think this feature is already on his list, but I'm CC-ing him just in case.

Cheers,
Andrey

================================================
Date: Fri, 25 Jan 2019 08:18:08 -0500
From: Richard Eisenberg <rae at cs.brynmawr.edu>
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: GHC <ghc-devs at haskell.org>
Subject: Re: Hadrian questions

Maybe I'm just lazy, but would it be possible to shorten these? Specifically, could there be a root-level file `build` that triggers Hadrian? That way, I could just say ./build instead of hadrian/build.sh.

Actually, even that isn't quite right. It is common, for example, for me to be deep in the testsuite, trying to fix a test. I twiddle something (say, the output file), and then I want to rerun the test. But now I have to go back out to the root of my tree to run the test, no? So: I think it would be very convenient to make a script we can all install (in our PATH) that will search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only one who would enjoy it.

Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, and I don't see a way to run just one directory of the testsuite. I use that ability currently quite often (because I know that I've mucked with the typechecker, so I just run the typecheck tests before doing full CI). Is this possible?

Thanks for all the work on this!
Richard


From lonetiger at gmail.com  Sun Jan 27 23:43:40 2019
From: lonetiger at gmail.com (Phyx)
Date: Sun, 27 Jan 2019 23:43:40 +0000
Subject: [ANNOUNCE] You should try Hadrian
In-Reply-To: <WM!ef52cdf3bcb17ddf070ef0a09062a4d8ec17e83e19b56164fc9463ae352c0512d1e2a5d2fe049d450f06cf5de601a2c2!@mailhub-mx2.ncl.ac.uk>
References: <AM6PR0702MB354355D50465344CD741050AA59B0@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>
 <CABHktDXMbpcpeQP9devqVpfvtNXQ-7U5HCJvTBoNdCCr_RYTJw@mail.gmail.com>
 <AM6PR0702MB3543F25FB4BA955204D0D06DA5950@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!bc843d34dac517516bd51882042ac67558d201471b519f7dabd03788e41db2d6c10420367fbfba5befdca844d353b442!@mailhub-mx5.ncl.ac.uk>
 <WM!ef52cdf3bcb17ddf070ef0a09062a4d8ec17e83e19b56164fc9463ae352c0512d1e2a5d2fe049d450f06cf5de601a2c2!@mailhub-mx2.ncl.ac.uk>
Message-ID: <CABHktDUUWK3MJuyZq-pQde5mKBxByQ4OfEe7nApmDGORqpMAcQ@mail.gmail.com>

Hi Andrey

On Sun, Jan 27, 2019 at 10:49 PM Andrey Mokhov <
andrey.mokhov at newcastle.ac.uk> wrote:

> Hi Tamar,
>
>
>
> Here is the relevant bullet point from the README:
>
>
>
> > On Windows, if you do not want to install MSYS, you can
>
> > use the Stack-based build script (Stack provides a managed
>
> > MSYS environment), as described in these instructions.
>
> > If you don't mind installing MSYS yourself or already have it,
>
> > you can use the Cabal-based build script.
>

Yes, I was referring to the "My first build" heading which had a call to
build.bat, but it seems my branch was just old and the file was updated 11
days ago to use cabal instead of stack.
Now the rest of the file also makes sense. Apologies for that, I thought I
had updated


>
> This claim is based on my experience. Installing the MSYS environment has
> never worked out smoothly for me. Doing this via Stack was indeed more
> robust (especially, when struggling with building GHC on Windows CI!). Has
> this been different in your experience?
>
>
>

Yes, stack does nothing special than just un-tar the binary distribution of
msys2. The problem is that this binary distribution is not kept up to date
unless things break. By that point they may have gotten so out of date that
the distribution simply can't even be upgraded. e.g. A while ago they used
a distribution that's so old it couldn't deal with pacman's invalidating
old certificates, which means you couldn't use it to update ca-certificates.

It also can't handle when msys upstream changes core dependencies. One such
update is a change in march that introduced a cyclic dependency between catgets
libcatgets and some packages. Or when they change the package layout as
they did removing the old shell scripts and making Mingw32.exe and
Mingw64.exe. I can name many more. The fact is the msys2 installers are set
up to work around these updates, or you must work around them when
initializing the environment to fix these.

And I see no evidence based on past issues that stack actually keeps their
msys2 installs up to date. So I don't want to go into the business of
managing stack msys2 issues for ghc builds.

> I'm just confused when it was decided to switch the defaults,
>
> > and why, without any consultation.
>
>
>
> I’m not sure what you mean. Could you clarify? The file `doc/windows.md`
> is 3 years old and hasn’t changed much since creation. The default build
> script `build.bat` currently uses Cabal:
>
>
>
> ```
>
> rem By default on Windows we build Hadrian using Cabal
>
> hadrian/build.cabal.bat %*
>
> ```
>

Yes.. I'm pretty sure when I looked at it before today it was pointing to
build.stack.bat, but that seems to be a two week old tree. So my fault
there.

Sorry, should have checked on gitlab!

Regards,
Tamar


>
>
> P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when
> moving to GitLab, and created this MR to fix this:
>
>
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/239
>
>
>
> Please jump into the comments there if you’d like me to fix/clarify
> anything.
>
>
>
> Thanks for reaching out!
>
>
>
> Cheers,
>
> Andrey
>
>
>
> *From:* Phyx [mailto:lonetiger at gmail.com]
> *Sent:* 27 January 2019 21:11
> *To:* Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Ben Gamari <
> ben at well-typed.com>
> *Cc:* GHC developers <ghc-devs at haskell.org>
> *Subject:* Re: [ANNOUNCE] You should try Hadrian
>
>
>
> Hi Andrey,
>
>
>
> I'm looking at
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and
> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md
>
> wondering why the default instructions for Windows are using stack, this
> isn't currently the case.
>
>
>
> In order for ./boot and configure to work already you need to be in an
> msys2 environment. So having stack install its own, un-updated msys2 is not
> a workflow I would recommend.
>
>
>
> There's a dubious claim there that using stack is "more robust", what is
> this claim based on?
>
> I'm just confused when it was decided to switch the defaults, and why,
> without any consultation.
>
>
>
> Regards,
>
> Tamar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190127/2cb9f5ed/attachment-0001.html>

From simonpj at microsoft.com  Mon Jan 28 10:13:09 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 28 Jan 2019 10:13:09 +0000
Subject: [GitLab] Introducing Marge-bot
In-Reply-To: <CABHktDXzecW3z5KQL426829ExFEn--oMZs94mz30+itZmCc_dw@mail.gmail.com>
References: <87k1iwbfja.fsf@smart-cactus.org>
 <CALuQ0m9brzJ9SRR2jGONC+VfaV9PgezWA4Gez7noO05R7ZMCKw@mail.gmail.com>
 <CABHktDXzecW3z5KQL426829ExFEn--oMZs94mz30+itZmCc_dw@mail.gmail.com>
Message-ID: <HE1PR8303MB007686C1F5623E5BF9D15B9FAD960@HE1PR8303MB0076.EURPRD83.prod.outlook.com>

I rather agree with Tamar here.

Not everyone can press the “commit to master” button.  (They were previously called “people with commit rights” but now I’m not sure what the appropriate name is.)  For those who do have such access, I think we should trust them to pull the trigger only when appropriate.  Yes, there will be errors of judgement sometimes – I have been guilty of such myself – but particularly with our new CI checks, these errors seldom harm others for long, and can be corrected by a subsequent commit.

By contrast, the frustration that Tamar describes can be quite demoralising, when (entirely without anyone intending this to happen) some small commit is unreasonably delayed.

We rely very strongly on people’s willingness to contribute, and should strive at every opportunity to remove barriers to doing so.   I suggest we just trust people’s judgement, backed by a CI validatation check.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Phyx
Sent: 26 January 2019 19:43
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: [GitLab] Introducing Marge-bot

> I also don't think one should be allowed to approve their own
> PR. If it is trivial enough to justify a self-accept then someone else
> should also be able to trivially accept it.

I disagree whole heartedly, as someone who's had to wait weeks for trivial patches to get reviews no thanks.
We should have a  formal definition of what is allowed to get committed as trivial much like a lot of open source
projects do and go from there.

I prefer a practical workflow, not just one that works for areas of the compiler where you have many people working,
It's a very frustrating experience otherwise.

Tamar.

On Wed, Jan 23, 2019 at 9:29 AM Matthew Pickering <matthewtpickering at gmail.com<mailto:matthewtpickering at gmail.com>> wrote:
It seems that in order for marge-bot to work best we need to
tighten up our policy towards merging so that it is only Marge
who performs the merges. I think Marge gets confused if people
push to master under her feet which means rebasing again and duplicating work.

Can we disable the "Merge when pipeline succeeds button" in order to
facilitate this?

I also don't think one should be allowed to approve their own
PR. If it is trivial enough to justify a self-accept then someone else
should also be able to trivially accept it.

Therefore I believe the correct workflow is:

1. Make a MR and assign it to someone if you want their specific review.
2. When the MR has been approved, the approver assigns the MR to marge.
3. Marge then performs the merge in her own time.

Cheers,

Matt

On Tue, Jan 22, 2019 at 8:31 PM Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:
>
> Hi everyone,
>
> As you might have noticed there is a new face on GitLab: Meet
> @marge-bot.
>
> Marge will be helping us with the pain of merging merge requests:
> Currently the typical workflow to merge an accepted MR involves the
> following:
>
>  1. Rebase the MR on top of the current `master` branch
>  2. Click on the "Merge when pipeline succeeds" button
>  3. Wait.
>  4. If another MR is merged before yours, return to step (1)
>
> Given the volume of patches that we have, this process gets tiresome
> quite quickly. Upstream knows [1] about this issue and is actively
> working towards a solution which will likely be ready in a few months.
>
> In the meantime, Marge automates this currently-manual process. With
> Marge merging a patch involves just two steps:
>
>  1. Ensure that the MR has at least one approval. This should happen in
>     the course of normal review but ping @bgamari, @alpmestan, @osa1, or
>     @tdammers if this was forgotten.
>
>  2. Use the "Assignee" field in the sidebar on the right side of the MR
>     to assign it to @marge-bot.
>
> Once Marge notices your MR she will dutifully watch over it, rebasing it
> as necessary until it is merged. If something goes awry, she will leave
> a (hopefully) helpful message and assign the MR back to you.
>
> So far Marge has been working out reasonably well and seems to be an
> improvement over the status quo. However, she still has some quirks so
> let me know if you think she is behaving erratically or otherwise have
> questions.
>
> Cheers,
>
> - Ben
> _______________________________________________
> 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%7Cc4c02ffbc7084916e7e208d683c68d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636841286138065701&sdata=ybQClPJNmWzmiD3Yur5VyfjN%2BCTNWtMDR1%2F928aUn60%3D&reserved=0>
_______________________________________________
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%7Cc4c02ffbc7084916e7e208d683c68d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636841286138075705&sdata=sJcidhcUoDS2pdvvCM7OXebzN7Bz2j9Sj3PpgAIoZcg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190128/3a5eca8a/attachment.html>

From alp at well-typed.com  Mon Jan 28 13:25:22 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Mon, 28 Jan 2019 14:25:22 +0100
Subject: Hadrian questions
In-Reply-To: <WM!51a5a5b9e2f54775dd324b91c89b1050e1dbbbbd21e9aaa21fa3091e12e8ce0d8edd37453ba7e2952cc1e38120701f0f!@mailhub-mx5.ncl.ac.uk>
References: <AM6PR0702MB3543EA8929ED0FB8D95DF4DBA5950@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!51a5a5b9e2f54775dd324b91c89b1050e1dbbbbd21e9aaa21fa3091e12e8ce0d8edd37453ba7e2952cc1e38120701f0f!@mailhub-mx5.ncl.ac.uk>
Message-ID: <0ba3bdd0-7124-8f72-0478-a423b206a5fe@well-typed.com>

Yes, this is on my TODO, along with a proper ./validate workflow (which 
combines binary distribution, installation and testing). I will do my 
best to provide a larger feature set in the upcoming weeks.

On 28/01/2019 00:15, Andrey Mokhov wrote:
> Hi Richard,
>
> First of all, thank you trying Hadrian and generating several new bug reports. This is very helpful!
>
>> I think it would be very convenient to make a script we can all install (in our PATH) that will
>> search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name
>> the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only
>> one who would enjoy it.
> This sounds like a good feature request to me. Could you please add it on Trac, so it's not lost?
>
>> Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md,
>> and I don't see a way to run just one directory of the testsuite. I use that ability currently quite
>> often (because I know that I've mucked with the typechecker, so I just run the typecheck tests
>> before doing full CI). Is this possible?
> Yes, this should be possible. I believe Alp is currently working on the testsuite with the goal of fully matching the functionality provided by the Make build system. I think this feature is already on his list, but I'm CC-ing him just in case.
>
> Cheers,
> Andrey
>
> ================================================
> Date: Fri, 25 Jan 2019 08:18:08 -0500
> From: Richard Eisenberg <rae at cs.brynmawr.edu>
> To: Matthew Pickering <matthewtpickering at gmail.com>
> Cc: GHC <ghc-devs at haskell.org>
> Subject: Re: Hadrian questions
>
> Maybe I'm just lazy, but would it be possible to shorten these? Specifically, could there be a root-level file `build` that triggers Hadrian? That way, I could just say ./build instead of hadrian/build.sh.
>
> Actually, even that isn't quite right. It is common, for example, for me to be deep in the testsuite, trying to fix a test. I twiddle something (say, the output file), and then I want to rerun the test. But now I have to go back out to the root of my tree to run the test, no? So: I think it would be very convenient to make a script we can all install (in our PATH) that will search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only one who would enjoy it.
>
> Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, and I don't see a way to run just one directory of the testsuite. I use that ability currently quite often (because I know that I've mucked with the typechecker, so I just run the typecheck tests before doing full CI). Is this possible?
>
> Thanks for all the work on this!
> Richard
>
-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England


From tdammers at gmail.com  Tue Jan 29 09:14:39 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Tue, 29 Jan 2019 10:14:39 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <875zuke5az.fsf@smart-cactus.org>
References: <875zuke5az.fsf@smart-cactus.org>
Message-ID: <20190129091438.auootjcibwpm6qu2@nibbler>

On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> 
> 
> For those following along at home:
> 
>    David has been looking at revising our contributor documentation.
>    He has started consolidating a variety of relevant content on the
>    Contributing page of the Wiki [1]. Below are my thoughts; feel free
>    to chime in with your own.

One more thought I'd like to throw out in the open here:

The current Newcomers' Guide uses the current Makefile workflow, but
this is on a fast track to deprecation - but then, I doubt Hadrian has
seen enough exposure yet to use for a good beginner-friendly "Just
Works" guide. I'm leaning towards sticking with make for now, also
because existing material is already written this way; and then once
Hadrian is truly ready for prime time, we can rewrite the relevant
parts.

Thoughts?

From klebinger.andreas at gmx.at  Tue Jan 29 13:08:15 2019
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Tue, 29 Jan 2019 14:08:15 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <mailman.6.1548763201.29927.ghc-devs@haskell.org>
References: <mailman.6.1548763201.29927.ghc-devs@haskell.org>
Message-ID: <5C50503F.1090607@gmx.at>

On hadrian:

Documentation will eventually catch up as more people use hadrian but 
imo things that
need to be supported are:

- Some workflows:
   * make fast
   * ./validate
   * make EXTRA_HC_OPTS="..."
- On windows build.bat defaults to stack which I think has never worked 
on my box.
- It's still too easy to run into hadrian bugs imo, which will probably 
work itself out in a few months.

There are also a few quality of life issues like ctrl+c not canceling 
the build on windows.
Which I hope will be resolved at some point but not sure if these should 
be showstoppers.

ghc-devs-request at haskell.org schrieb:
> One more thought I'd like to throw out in the open here:
>
> The current Newcomers' Guide uses the current Makefile workflow, but
> this is on a fast track to deprecation - but then, I doubt Hadrian has
> seen enough exposure yet to use for a good beginner-friendly "Just
> Works" guide. I'm leaning towards sticking with make for now, also
> because existing material is already written this way; and then once
> Hadrian is truly ready for prime time, we can rewrite the relevant
> parts.
>
> Thoughts?


From simonpj at microsoft.com  Tue Jan 29 15:03:39 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Jan 2019 15:03:39 +0000
Subject: hcs2hs failure
Message-ID: <HE1PR8303MB00767D343E5770542187DEC4AD970@HE1PR8303MB0076.EURPRD83.prod.outlook.com>

Is anyone else seeing this in a GHC build

utils/hsc2hs/HSCParser.hs:170:14: error: [-Wunused-matches, -Werror=unused-matches]

    Defined but not used: 'd'

    |

170 |         '\'':d:'\'':_ -> do any3Chars_; text -- Case 2

    |              ^
Indeed, d looks unused.  But this line of code has been there since 28 Dec, so I can't understand why it has not bitten before.
With -Werror my build fails.  I could switch to -Wwarn, but I think -Werror is the default.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190129/a6d6fc1d/attachment.html>

From sgraf1337 at gmail.com  Tue Jan 29 16:36:10 2019
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Tue, 29 Jan 2019 17:36:10 +0100
Subject: [ANNOUNCE] You should try Hadrian
In-Reply-To: <CABHktDUUWK3MJuyZq-pQde5mKBxByQ4OfEe7nApmDGORqpMAcQ@mail.gmail.com>
References: <AM6PR0702MB354355D50465344CD741050AA59B0@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!9820810dbf9fe121771bbee993016b267df9e03d3b7d303f99955624c6d40074cdd5d102a3e884d4674c21f79630cbed!@mailhub-mx4.ncl.ac.uk>
 <CABHktDXMbpcpeQP9devqVpfvtNXQ-7U5HCJvTBoNdCCr_RYTJw@mail.gmail.com>
 <AM6PR0702MB3543F25FB4BA955204D0D06DA5950@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!bc843d34dac517516bd51882042ac67558d201471b519f7dabd03788e41db2d6c10420367fbfba5befdca844d353b442!@mailhub-mx5.ncl.ac.uk>
 <WM!ef52cdf3bcb17ddf070ef0a09062a4d8ec17e83e19b56164fc9463ae352c0512d1e2a5d2fe049d450f06cf5de601a2c2!@mailhub-mx2.ncl.ac.uk>
 <CABHktDUUWK3MJuyZq-pQde5mKBxByQ4OfEe7nApmDGORqpMAcQ@mail.gmail.com>
Message-ID: <CAAS+=P9XAdShUp8HL_5oecityEaSPNSuzg9XwFkzuwupEjrV2Q@mail.gmail.com>

Side note: On my Windows my machine, where I use the environment provided
by `stack exec --no-ghc-package-path bash`, I have to do `bash -c 'pushd .
&& . /etc/profile && popd && ./configure --enable-tarballs-autodownload'`
or something along those lines for some time now (probably since the boot
script has been rewritten to python?).

Am Mo., 28. Jan. 2019 um 00:44 Uhr schrieb Phyx <lonetiger at gmail.com>:

> Hi Andrey
>
> On Sun, Jan 27, 2019 at 10:49 PM Andrey Mokhov <
> andrey.mokhov at newcastle.ac.uk> wrote:
>
>> Hi Tamar,
>>
>>
>>
>> Here is the relevant bullet point from the README:
>>
>>
>>
>> > On Windows, if you do not want to install MSYS, you can
>>
>> > use the Stack-based build script (Stack provides a managed
>>
>> > MSYS environment), as described in these instructions.
>>
>> > If you don't mind installing MSYS yourself or already have it,
>>
>> > you can use the Cabal-based build script.
>>
>
> Yes, I was referring to the "My first build" heading which had a call to
> build.bat, but it seems my branch was just old and the file was updated 11
> days ago to use cabal instead of stack.
> Now the rest of the file also makes sense. Apologies for that, I thought I
> had updated
>
>
>>
>> This claim is based on my experience. Installing the MSYS environment has
>> never worked out smoothly for me. Doing this via Stack was indeed more
>> robust (especially, when struggling with building GHC on Windows CI!). Has
>> this been different in your experience?
>>
>>
>>
>
> Yes, stack does nothing special than just un-tar the binary distribution
> of msys2. The problem is that this binary distribution is not kept up to
> date unless things break. By that point they may have gotten so out of date
> that the distribution simply can't even be upgraded. e.g. A while ago they
> used a distribution that's so old it couldn't deal with pacman's
> invalidating old certificates, which means you couldn't use it to update
> ca-certificates.
>
> It also can't handle when msys upstream changes core dependencies. One
> such update is a change in march that introduced a cyclic dependency
> between catgets libcatgets and some packages. Or when they change the
> package layout as they did removing the old shell scripts and making
> Mingw32.exe and Mingw64.exe. I can name many more. The fact is the msys2
> installers are set up to work around these updates, or you must work around
> them when initializing the environment to fix these.
>
> And I see no evidence based on past issues that stack actually keeps their
> msys2 installs up to date. So I don't want to go into the business of
> managing stack msys2 issues for ghc builds.
>
> > I'm just confused when it was decided to switch the defaults,
>>
>> > and why, without any consultation.
>>
>>
>>
>> I’m not sure what you mean. Could you clarify? The file `doc/windows.md`
>> is 3 years old and hasn’t changed much since creation. The default build
>> script `build.bat` currently uses Cabal:
>>
>>
>>
>> ```
>>
>> rem By default on Windows we build Hadrian using Cabal
>>
>> hadrian/build.cabal.bat %*
>>
>> ```
>>
>
> Yes.. I'm pretty sure when I looked at it before today it was pointing to
> build.stack.bat, but that seems to be a two week old tree. So my fault
> there.
>
> Sorry, should have checked on gitlab!
>
> Regards,
> Tamar
>
>
>>
>>
>> P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when
>> moving to GitLab, and created this MR to fix this:
>>
>>
>>
>> https://gitlab.haskell.org/ghc/ghc/merge_requests/239
>>
>>
>>
>> Please jump into the comments there if you’d like me to fix/clarify
>> anything.
>>
>>
>>
>> Thanks for reaching out!
>>
>>
>>
>> Cheers,
>>
>> Andrey
>>
>>
>>
>> *From:* Phyx [mailto:lonetiger at gmail.com]
>> *Sent:* 27 January 2019 21:11
>> *To:* Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Ben Gamari <
>> ben at well-typed.com>
>> *Cc:* GHC developers <ghc-devs at haskell.org>
>> *Subject:* Re: [ANNOUNCE] You should try Hadrian
>>
>>
>>
>> Hi Andrey,
>>
>>
>>
>> I'm looking at
>> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and
>> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md
>>
>> wondering why the default instructions for Windows are using stack, this
>> isn't currently the case.
>>
>>
>>
>> In order for ./boot and configure to work already you need to be in an
>> msys2 environment. So having stack install its own, un-updated msys2 is not
>> a workflow I would recommend.
>>
>>
>>
>> There's a dubious claim there that using stack is "more robust", what is
>> this claim based on?
>>
>> I'm just confused when it was decided to switch the defaults, and why,
>> without any consultation.
>>
>>
>>
>> Regards,
>>
>> Tamar
>>
> _______________________________________________
> 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/20190129/c151d1d3/attachment.html>

From julian at leviston.net  Tue Jan 29 20:09:25 2019
From: julian at leviston.net (Julian Leviston)
Date: Wed, 30 Jan 2019 07:09:25 +1100
Subject: Thoughts on the Contributing page
In-Reply-To: <20190129091438.auootjcibwpm6qu2@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190129091438.auootjcibwpm6qu2@nibbler>
Message-ID: <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>


> On 29 Jan 2019, at 8:14 pm, Tobias Dammers <tdammers at gmail.com> wrote:
> 
> The current Newcomers' Guide uses the current Makefile workflow, but
> this is on a fast track to deprecation - but then, I doubt Hadrian has
> seen enough exposure yet to use for a good beginner-friendly "Just
> Works" guide. I'm leaning towards sticking with make for now, also
> because existing material is already written this way; and then once
> Hadrian is truly ready for prime time, we can rewrite the relevant
> parts.
> 
> Thoughts?

As a recent newcomer, it’d be nice to have the option there as a link with a warning sign “here be dragons, but try this out if you’re interested”.
I tried it. It seems better than regular make already (I don’t have to guess at appropriate concurrency, for example, I just throw -j at it and it works it out assumedly because GHC can work out the number of capabilities), and it seems to work out which builds it needs to do next automatically.
Both those things - at least - are more beginner friendly than manually cloning the mk/build.mk file, running ./boot && ./configure && make -j8 then adjusting the mk/build.mk file again to get make to be faster.

So, FWIW, I say put the link on the page at the top as an alternative, mark it with a warning saying something along the lines of that it might not work, but it’s the future, and it’s simpler and easier if it does, and feel free to try it out, then fallback to make. There are plenty of sharp rocks for beginners, and ironically the existing make-based build system is probably one of them. (Having said that, it’s very helpful to know the stages of compilation, so hopefully whatever docs we arrive at will point the beginner to something explaining what’s going on as they do their first bootstrapping build, for the curious.

Julian

From matthewtpickering at gmail.com  Wed Jan 30 14:19:39 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 30 Jan 2019 14:19:39 +0000
Subject: hcs2hs failure
In-Reply-To: <HE1PR8303MB00767D343E5770542187DEC4AD970@HE1PR8303MB0076.EURPRD83.prod.outlook.com>
References: <HE1PR8303MB00767D343E5770542187DEC4AD970@HE1PR8303MB0076.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m8vamJ0wc-UV6TCoKdgp_-NOAQSOgBu8sDyTVcAoY=U+Q@mail.gmail.com>

Simon,

Unfortunately -Werror seems to have not been enabled on CI builds
since the gitlab migration.

Along with Sebastian I am working to fix that here:
https://gitlab.haskell.org/ghc/ghc/merge_requests/257

Cheers,

Matt

On Tue, Jan 29, 2019 at 3:04 PM Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> Is anyone else seeing this in a GHC build
>
> utils/hsc2hs/HSCParser.hs:170:14: error: [-Wunused-matches, -Werror=unused-matches]
>
>     Defined but not used: ‘d’
>
>     |
>
> 170 |         '\'':d:'\'':_ -> do any3Chars_; text -- Case 2
>
>     |              ^
>
> Indeed, d looks unused.  But this line of code has been there since 28 Dec, so I can’t understand why it has not bitten before.
>
> With -Werror my build fails.  I could switch to -Wwarn, but I think -Werror is the default.
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From tdammers at gmail.com  Wed Jan 30 14:55:51 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Wed, 30 Jan 2019 15:55:51 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190129091438.auootjcibwpm6qu2@nibbler>
 <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>
Message-ID: <20190130145550.zmk3bw4pz7iwrm3k@nibbler>

On Wed, Jan 30, 2019 at 07:09:25AM +1100, Julian Leviston wrote:
> As a recent newcomer, it’d be nice to have the option there as a link
> with a warning sign “here be dragons, but try this out if you’re
> interested”.  I tried it. It seems better than regular make already (I
> don’t have to guess at appropriate concurrency, for example, I just
> throw -j at it and it works it out assumedly because GHC can work out
> the number of capabilities), and it seems to work out which builds it
> needs to do next automatically.  Both those things - at least - are
> more beginner friendly than manually cloning the mk/build.mk file,
> running ./boot && ./configure && make -j8 then adjusting the
> mk/build.mk file again to get make to be faster.
>
> So, FWIW, I say put the link on the page at the top as an alternative,
> mark it with a warning saying something along the lines of that it
> might not work, but it’s the future, and it’s simpler and easier if it
> does, and feel free to try it out, then fallback to make. There are
> plenty of sharp rocks for beginners, and ironically the existing
> make-based build system is probably one of them. (Having said that,
> it’s very helpful to know the stages of compilation, so hopefully
> whatever docs we arrive at will point the beginner to something
> explaining what’s going on as they do their first bootstrapping build,
> for the curious.

Actually, after talking to both the Simons as well as Alp, one of the
core people in the Hadrian project (if not the mastermind), we
tentatively decided to write the Newcomers' Guide for Hadrian, not Make.
In principle, Hadrian should be able to do everything that is needed for
this, and the "regular" code paths have been tested extensively, and as
you have noticed, it is a lot more user friendly. We may still want to
link to the Make-based build instructions somewhere, but present
Hadrian as the default option.

A short explanation of build stages will of course still be in the Guide
- they are just as relevant to Hadrian as they are to the Make build
system. However, the tutorial is quite long as it is already, so I want
to keep it as short as possible, delegating in-depth explanations to
other (ideally existing) wiki pages.

If you like, you can follow along with my progress:

https://github.com/tdammers/ghc-wiki/blob/wip/newcomers/newcomers-tutorial.md


From matthewtpickering at gmail.com  Wed Jan 30 15:01:24 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 30 Jan 2019 15:01:24 +0000
Subject: Thoughts on the Contributing page
In-Reply-To: <20190130145550.zmk3bw4pz7iwrm3k@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190129091438.auootjcibwpm6qu2@nibbler>
 <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>
 <20190130145550.zmk3bw4pz7iwrm3k@nibbler>
Message-ID: <CALuQ0m-2HT10LM-voWdmb67UeLMavYpRtNj=1s9zeL+UwRt9EQ@mail.gmail.com>

Whilst we're at it, is there any consensus to make the default build
settings more friendly to developers?

The default is still perf which takes a very long time. devel2 would
be an appropriate choice I think for newcomers.

Matt

On Wed, Jan 30, 2019 at 2:56 PM Tobias Dammers <tdammers at gmail.com> wrote:
>
> On Wed, Jan 30, 2019 at 07:09:25AM +1100, Julian Leviston wrote:
> > As a recent newcomer, it’d be nice to have the option there as a link
> > with a warning sign “here be dragons, but try this out if you’re
> > interested”.  I tried it. It seems better than regular make already (I
> > don’t have to guess at appropriate concurrency, for example, I just
> > throw -j at it and it works it out assumedly because GHC can work out
> > the number of capabilities), and it seems to work out which builds it
> > needs to do next automatically.  Both those things - at least - are
> > more beginner friendly than manually cloning the mk/build.mk file,
> > running ./boot && ./configure && make -j8 then adjusting the
> > mk/build.mk file again to get make to be faster.
> >
> > So, FWIW, I say put the link on the page at the top as an alternative,
> > mark it with a warning saying something along the lines of that it
> > might not work, but it’s the future, and it’s simpler and easier if it
> > does, and feel free to try it out, then fallback to make. There are
> > plenty of sharp rocks for beginners, and ironically the existing
> > make-based build system is probably one of them. (Having said that,
> > it’s very helpful to know the stages of compilation, so hopefully
> > whatever docs we arrive at will point the beginner to something
> > explaining what’s going on as they do their first bootstrapping build,
> > for the curious.
>
> Actually, after talking to both the Simons as well as Alp, one of the
> core people in the Hadrian project (if not the mastermind), we
> tentatively decided to write the Newcomers' Guide for Hadrian, not Make.
> In principle, Hadrian should be able to do everything that is needed for
> this, and the "regular" code paths have been tested extensively, and as
> you have noticed, it is a lot more user friendly. We may still want to
> link to the Make-based build instructions somewhere, but present
> Hadrian as the default option.
>
> A short explanation of build stages will of course still be in the Guide
> - they are just as relevant to Hadrian as they are to the Make build
> system. However, the tutorial is quite long as it is already, so I want
> to keep it as short as possible, delegating in-depth explanations to
> other (ideally existing) wiki pages.
>
> If you like, you can follow along with my progress:
>
> https://github.com/tdammers/ghc-wiki/blob/wip/newcomers/newcomers-tutorial.md
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From tdammers at gmail.com  Wed Jan 30 15:10:07 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Wed, 30 Jan 2019 16:10:07 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <CALuQ0m-2HT10LM-voWdmb67UeLMavYpRtNj=1s9zeL+UwRt9EQ@mail.gmail.com>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190129091438.auootjcibwpm6qu2@nibbler>
 <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>
 <20190130145550.zmk3bw4pz7iwrm3k@nibbler>
 <CALuQ0m-2HT10LM-voWdmb67UeLMavYpRtNj=1s9zeL+UwRt9EQ@mail.gmail.com>
Message-ID: <20190130151006.auemouzxo6chl77u@nibbler>

On Wed, Jan 30, 2019 at 03:01:24PM +0000, Matthew Pickering wrote:
> Whilst we're at it, is there any consensus to make the default build
> settings more friendly to developers?
> 
> The default is still perf which takes a very long time. devel2 would
> be an appropriate choice I think for newcomers.

The way I wrote it right now is that for the very first build, you use
whatever default GHC ships with, just to make sure you succeed in making
a clean build on a pristine checkout. After that, I do recommend using
the "devel2" flavour.

I do believe that release build settings should be the default though,
simply because of the "install from source" use case. Aspiring GHC
hackers will have to learn how to configure the build anyway, might as
well teach them right away.

From matthewtpickering at gmail.com  Wed Jan 30 15:42:22 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 30 Jan 2019 15:42:22 +0000
Subject: Why are nested brackets disallowed?
In-Reply-To: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
References: <CALuQ0m8DmEG_59RS+FokP9+Jo0WxkR1HE5eFN0J-rmwzTACZeA@mail.gmail.com>
Message-ID: <CALuQ0m8HWDXr47fRtfOxMd+_dQ8eO52Qg7JfUe1cB11Q5+u9zA@mail.gmail.com>

I put up a patch which removes this restriction (for untyped expressions).

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

On Thu, Jan 24, 2019 at 11:46 AM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> There is a check in `RnSplice` which errors on the following program
> with nested brackets.
>
> ```
> prog = [| [| True |] |]
>
> T.hs:4:11: error:
>     • Template Haskell brackets cannot be nested (without intervening splices)
>     • In the Template Haskell quotation [| True |]
>       In the Template Haskell quotation [| [| True |] |]
>   |
> 4 | prog = [| [| True |] |]
>   |           ^^^^^^^^^^
>
> ```
>
> As far as I can see the check was added in 2013 in this commit,
> https://github.com/ghc/ghc/commit/d0d47ba76f8f0501cf3c4966bc83966ab38cac27#diff-58794f81a415f148d011de563988c2b5R170
>
> But there is no note, no tests and no comment about why it was added.
>
> I removed the check and added a `BracketE` constructor to the
> template-haskell AST and the
> code compiles fine.
>
> I can also construct a program which needs to be spliced twice and
> this also works fine.
>
> ```
> func Add = [| (+) |]
> func Mul = [| (*) |]
>
> f1 "+" = [| Add |]
> f1 "*" = [| Mul |]
>
> comb s = [| func $(f1 s) |]
> ```
> ```
> res = $($(comb "*"))
> ```
>
> So it seems the restriction is quite arbitrary but I was wondering if
> I was missing some limitation which meant this check was added. I
> would not be surprised if something more complicated goes wrong with
> splicing.
>
> Cheers,
>
> Matt

From alp at well-typed.com  Wed Jan 30 19:22:41 2019
From: alp at well-typed.com (Alp Mestanogullari)
Date: Wed, 30 Jan 2019 20:22:41 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <5C50503F.1090607@gmx.at>
References: <mailman.6.1548763201.29927.ghc-devs@haskell.org>
 <5C50503F.1090607@gmx.at>
Message-ID: <8ec2c83c-12b9-f412-f6b6-1a749554689e@well-typed.com>

Hello,

On 29/01/2019 14:08, Andreas Klebinger wrote:
> On hadrian:
>
> Documentation will eventually catch up as more people use hadrian but 
> imo things that
> need to be supported are:
>
> - Some workflows:
>   * make fast
Right, so we're in the process of discussing something very much related 
at https://ghc.haskell.org/trac/ghc/ticket/16253. For reference, this is 
what 'make fast' does: 
https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Skipdependencybuilding
>   * ./validate
I'm in the process of tweaking the validate script to have an 
'--hadrian' mode. I'll document it as soon as it works, along the code 
changes, in the upcoming merge request.
>   * make EXTRA_HC_OPTS="..."
I think you can already achieve this (but it's perhaps not documented in 
'make.md'), with the flavour/user settings mechanism: 
https://github.com/ghc/ghc/blob/master/hadrian/doc/user-settings.md (see 
for example the different 'userArgs' definitions).
> - On windows build.bat defaults to stack which I think has never 
> worked on my box.
Andrey? (cc'd him)

>
> There are also a few quality of life issues like ctrl+c not canceling 
> the build on windows.
> Which I hope will be resolved at some point but not sure if these 
> should be showstoppers.
>
> ghc-devs-request at haskell.org schrieb:
>> One more thought I'd like to throw out in the open here:
>>
>> The current Newcomers' Guide uses the current Makefile workflow, but
>> this is on a fast track to deprecation - but then, I doubt Hadrian has
>> seen enough exposure yet to use for a good beginner-friendly "Just
>> Works" guide. I'm leaning towards sticking with make for now, also
>> because existing material is already written this way; and then once
>> Hadrian is truly ready for prime time, we can rewrite the relevant
>> parts.
>>
>> Thoughts?
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England


From andrey.mokhov at newcastle.ac.uk  Wed Jan 30 19:43:27 2019
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Wed, 30 Jan 2019 19:43:27 +0000
Subject: Thoughts on the Contributing page
In-Reply-To: <WM!5fb6fc1999400ca396c17b9ed73f5efafdbf82641a26c7d82a0a6364b264e3e8a3ef4599e0633a27e024dd7a17e7c8c9!@mailhub-mx4.ncl.ac.uk>
References: <mailman.6.1548763201.29927.ghc-devs@haskell.org>
 <5C50503F.1090607@gmx.at>
 <8ec2c83c-12b9-f412-f6b6-1a749554689e@well-typed.com>
 <WM!5fb6fc1999400ca396c17b9ed73f5efafdbf82641a26c7d82a0a6364b264e3e8a3ef4599e0633a27e024dd7a17e7c8c9!@mailhub-mx4.ncl.ac.uk>
 <AM6PR0702MB3543C6132C4199610CBC8611A5900@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!2a1b05f259d38093869d72f5deb73c9fccb9f48fba743657613b425ad78ee85fc5c186c8c4c9c053d207446a91c6a52b!@mailhub-mx4.ncl.ac.uk>

Andreas, Alp:

> > - On windows build.bat defaults to stack which I think has never 
> > worked on my box.
> Andrey? (cc'd him)

Actually `build.bat` calls the Cabal-based build script. This was a relatively recent change, and we plan to stick to it in the long term, while still providing an alternative `build.stack.bat`.

> There are also a few quality of life issues like ctrl+c not canceling 
> the build on windows.
> Which I hope will be resolved at some point but not sure if these 
> should be showstoppers.

Indeed. I hope it's not difficult to fix this, but I'm not sure where to start. Any suggestions are very welcome.

Cheers,
Andrey

From lonetiger at gmail.com  Wed Jan 30 20:05:07 2019
From: lonetiger at gmail.com (Phyx)
Date: Wed, 30 Jan 2019 20:05:07 +0000
Subject: Thoughts on the Contributing page
In-Reply-To: <WM!2a1b05f259d38093869d72f5deb73c9fccb9f48fba743657613b425ad78ee85fc5c186c8c4c9c053d207446a91c6a52b!@mailhub-mx4.ncl.ac.uk>
References: <mailman.6.1548763201.29927.ghc-devs@haskell.org>
 <5C50503F.1090607@gmx.at>
 <8ec2c83c-12b9-f412-f6b6-1a749554689e@well-typed.com>
 <AM6PR0702MB3543C6132C4199610CBC8611A5900@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!5fb6fc1999400ca396c17b9ed73f5efafdbf82641a26c7d82a0a6364b264e3e8a3ef4599e0633a27e024dd7a17e7c8c9!@mailhub-mx4.ncl.ac.uk>
 <WM!2a1b05f259d38093869d72f5deb73c9fccb9f48fba743657613b425ad78ee85fc5c186c8c4c9c053d207446a91c6a52b!@mailhub-mx4.ncl.ac.uk>
Message-ID: <CABHktDXfivBMjLRf_HkhRgF8K1ykVWP9tok5ymcS8vOxf+vLmQ@mail.gmail.com>

>
> Indeed. I hope it's not difficult to fix this, but I'm not sure where to
> start. Any suggestions are very welcome.
>
>
It is unfortunately, because it's not a bug. Odds are both of you are using
MinTTY which people blindly recommend to use.
The problem is MinTTY is not designed to run native Windows applications,
it is designed to run ported POSIX applications. e.g. things linked against
the
msys2/cygwin runtime. Because of this it implements a very intrusive hack
in order to be able to handle signals the way they would be under a posix
application,
which simply isn't compatible with Windows signals see
https://github.com/mintty/mintty/issues/56

Because your build is triggered by a batch file, when you press ctrl+c
mintty will terminate the parent process indiscriminately if it's a script,
e.g. the batch process is killed but
none of the children are.  This is why ghci has ghcii.sh as a workaround.
e.g. why pressing ctrl+c terminate ghci instead of the computation as we
can't.

this is why you should not use MinTTY with a native Windows application.
MinTTY also introduces a number of character encoding problems for native
Windows applications, see
https://github.com/mintty/mintty/wiki/Tips#inputoutput-interaction-with-alien-programs.
In short, the issues you're seeing are by design.

Now you have two options:

1) Don't use mintty, instead use something like ConEmu
https://conemu.github.io/ with bash.exe from msys2 as the terminal
host.This will work for Native application but have
issues with interactive posix applications like msys2 gdb (mingw64 gdb
should in theory work fine though, but it's slightly more limited) and
i.e.. tmux won't work. (the problems are thus flipped).

2) Use WinPTY https://github.com/rprichard/winpty to wrap native
application calls (you can just install it via pacman), which works and you
can keep using MinTTY, but this does have a slight performance overhead
as the reason it works is that it spawns a hidden buffer and scrapes output
from it and send events to it to check the native behavior for Windows
applications.

TL;DR; It's not a simple issue, the application can only deal with one
signal processing method at a time.

Cheers,
Tamar


> Cheers,
> Andrey
> _______________________________________________
> 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/20190130/2f6a2c50/attachment.html>

From ben at smart-cactus.org  Thu Jan 31 01:40:04 2019
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 30 Jan 2019 20:40:04 -0500
Subject: Thoughts on the Contributing page
In-Reply-To: <20190130151006.auemouzxo6chl77u@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190129091438.auootjcibwpm6qu2@nibbler>
 <121E6FFC-CA07-463B-BF70-303DB63049E8@leviston.net>
 <20190130145550.zmk3bw4pz7iwrm3k@nibbler>
 <CALuQ0m-2HT10LM-voWdmb67UeLMavYpRtNj=1s9zeL+UwRt9EQ@mail.gmail.com>
 <20190130151006.auemouzxo6chl77u@nibbler>
Message-ID: <875zu5d2q7.fsf@smart-cactus.org>

Tobias Dammers <tdammers at gmail.com> writes:

> On Wed, Jan 30, 2019 at 03:01:24PM +0000, Matthew Pickering wrote:
>> Whilst we're at it, is there any consensus to make the default build
>> settings more friendly to developers?
>> 
>> The default is still perf which takes a very long time. devel2 would
>> be an appropriate choice I think for newcomers.
>
> The way I wrote it right now is that for the very first build, you use
> whatever default GHC ships with, just to make sure you succeed in making
> a clean build on a pristine checkout. After that, I do recommend using
> the "devel2" flavour.
>
> I do believe that release build settings should be the default though,
> simply because of the "install from source" use case. Aspiring GHC
> hackers will have to learn how to configure the build anyway, might as
> well teach them right away.

Agreed. The default in a clean checkout should remain perf.

However, it would be reasonable for the newcomers instructions to start
off with devel2. For most contributors working in compiler/ this is the
right default.

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/20190130/175645a7/attachment.sig>

From tdammers at gmail.com  Thu Jan 31 15:48:24 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Thu, 31 Jan 2019 16:48:24 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <875zuke5az.fsf@smart-cactus.org>
References: <875zuke5az.fsf@smart-cactus.org>
Message-ID: <20190131154823.gf6wzwgj7yvhunmt@nibbler>

One more thing I noticed: the current Newcomers instructions say to
clone git://github.com/ghc/ghc, but if you're going to use the
gitlab-based MR workflow later on, cloning the gitlab repo directly is
going to be a lot more convenient. And then there's also
git.haskell.org, which is what I've been using so far.

So which one of these should we tell people to clone? I'm inclined to
recommend the following workflow:

1. Create gitlab account as needed
2. Fork the GHC project
3. Clone your fork from gitlab
4. Create feature branch
5. Make changes, squash, validate, rebase, push to fork
6. Create MR on gitlab

This would keep the hassle to a minimum for a new contributor, and does
not require push permissions on `ghc/ghc`.

On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> 
> 
> For those following along at home:
> 
>    David has been looking at revising our contributor documentation.
>    He has started consolidating a variety of relevant content on the
>    Contributing page of the Wiki [1]. Below are my thoughts; feel free
>    to chime in with your own.
> 
> 
> David,
> 
> The contributing page is looking quite good. However, I do wonder
> whether we could reduce the link "fan-out" a bit more: it still rather
> feels like a collection of links with no clear "beginning".
> 
> The "Newcomers to GHC" section is a great start but I see two
> potential issues:
> 
>  * we don't clearly articulate the precise steps that a newcomer will
>    need to take
> 
>  * the first thing we mention are four links which, while useful,
>    constitute a significant volume of reading for a newcomer.
>    I fear we may lose people at this point.
> 
> Regarding the second point, I think that WorkingConventions/FixingBugs is a
> good model in that it clearly lists a series of concrete steps that the
> contributor should take. Admittedly, I think some of the detail should
> be dropped or moved (e.g. the mention of setting git's user.name
> variable is likely unnecessary in 2019).
> 
> I think that something similar to this list should be the first thing
> one sees when they reach the contributing page. Ideally the "typical"
> case of a new contributor wanting to submit their first patch would be
> able to gather everything they need to get started in one or two
> screenfuls of text. After that prose can come additional links to
> more in-depth documentation.
> 
> Other various issues I noticed:
> 
>  * We link to wiki:WorkingConventions from a variety of places
>    (including wiki:Contributing) but it is now just a link to
>    wiki:Contributing.
> 
>  * wiki:WorkingConventions/FixingBugs still has references to
>    Phabricator. In general we should start culling such references.
> 
>  * wiki:WorkingConventions/FixingBugs also has references to Trac
>    documentation. We should try to replace these with the relevant
>    GitLab documentation when we migrate.
> 
>  * wiki:WorkingConventions/FixingBugs should be updated to reflect
>    that GitLab CI is now the source of truth for validation.
> 
>  * I don't know exactly how this should look but I think we need to do a
>    better job of concisely stating what we expect of contributions. That
>    is:
> 
>      * commit messages should be readable and discuss what the patch
>        does. "Fixes #NNNN" is not an adequate commit message.
> 
>      * changes should be commented where necessary (my usual rule of
>        thumb is "write the comment you would have liked to read when you
>        started writing your patch"). We should mention the Note
>        convention.
> 
>      * commit messages and comments should refer to ticket numbers where
>        appropriate (e.g. using usual #NNNN syntax; people often get this
>        wrong).
> 
>      * commits should be either squashed or logically distinct,
>        individually buildable changes.
> 
>      * changes to most of `base` need to go through the CLC (this may be
>        optional as defining what set of `base` this applies to is a bit
>        tricky; in the interest of keeping things concise we may be
>        better off handling this personally on a case-by-case basis)
> 
>      * code changes should conform to GHC's (somewhat fluid, for better
>        or worse) code style
>        (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)
> 
>      * thought should be given to testing
> 
>     Having a document which succinctly summarised these expectations as
>     we could easily refer to it during code review. Even better, we
>     could excerpt it as a checklist in our merge request description
>     template (I have put up an initial attempt at this as !149).
> 
> Anyways, there is more to be said here but this email is getting a bit
> long so let's leave it for future discussions.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Contributing



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


-- 
Tobias Dammers - tdammers at gmail.com

From matthewtpickering at gmail.com  Thu Jan 31 15:57:20 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 31 Jan 2019 15:57:20 +0000
Subject: Thoughts on the Contributing page
In-Reply-To: <20190131154823.gf6wzwgj7yvhunmt@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190131154823.gf6wzwgj7yvhunmt@nibbler>
Message-ID: <CALuQ0m8Zy-ojfDQKF+QS=8cw=Z_m2XUfM2uXjBLzVTTun=rQHg@mail.gmail.com>

I think you should suggest cloning the main ghc repo and adding the
fork as a remote. This is the usual github workflow.

On Thu, Jan 31, 2019 at 3:48 PM Tobias Dammers <tdammers at gmail.com> wrote:
>
> One more thing I noticed: the current Newcomers instructions say to
> clone git://github.com/ghc/ghc, but if you're going to use the
> gitlab-based MR workflow later on, cloning the gitlab repo directly is
> going to be a lot more convenient. And then there's also
> git.haskell.org, which is what I've been using so far.
>
> So which one of these should we tell people to clone? I'm inclined to
> recommend the following workflow:
>
> 1. Create gitlab account as needed
> 2. Fork the GHC project
> 3. Clone your fork from gitlab
> 4. Create feature branch
> 5. Make changes, squash, validate, rebase, push to fork
> 6. Create MR on gitlab
>
> This would keep the hassle to a minimum for a new contributor, and does
> not require push permissions on `ghc/ghc`.
>
> On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> >
> >
> > For those following along at home:
> >
> >    David has been looking at revising our contributor documentation.
> >    He has started consolidating a variety of relevant content on the
> >    Contributing page of the Wiki [1]. Below are my thoughts; feel free
> >    to chime in with your own.
> >
> >
> > David,
> >
> > The contributing page is looking quite good. However, I do wonder
> > whether we could reduce the link "fan-out" a bit more: it still rather
> > feels like a collection of links with no clear "beginning".
> >
> > The "Newcomers to GHC" section is a great start but I see two
> > potential issues:
> >
> >  * we don't clearly articulate the precise steps that a newcomer will
> >    need to take
> >
> >  * the first thing we mention are four links which, while useful,
> >    constitute a significant volume of reading for a newcomer.
> >    I fear we may lose people at this point.
> >
> > Regarding the second point, I think that WorkingConventions/FixingBugs is a
> > good model in that it clearly lists a series of concrete steps that the
> > contributor should take. Admittedly, I think some of the detail should
> > be dropped or moved (e.g. the mention of setting git's user.name
> > variable is likely unnecessary in 2019).
> >
> > I think that something similar to this list should be the first thing
> > one sees when they reach the contributing page. Ideally the "typical"
> > case of a new contributor wanting to submit their first patch would be
> > able to gather everything they need to get started in one or two
> > screenfuls of text. After that prose can come additional links to
> > more in-depth documentation.
> >
> > Other various issues I noticed:
> >
> >  * We link to wiki:WorkingConventions from a variety of places
> >    (including wiki:Contributing) but it is now just a link to
> >    wiki:Contributing.
> >
> >  * wiki:WorkingConventions/FixingBugs still has references to
> >    Phabricator. In general we should start culling such references.
> >
> >  * wiki:WorkingConventions/FixingBugs also has references to Trac
> >    documentation. We should try to replace these with the relevant
> >    GitLab documentation when we migrate.
> >
> >  * wiki:WorkingConventions/FixingBugs should be updated to reflect
> >    that GitLab CI is now the source of truth for validation.
> >
> >  * I don't know exactly how this should look but I think we need to do a
> >    better job of concisely stating what we expect of contributions. That
> >    is:
> >
> >      * commit messages should be readable and discuss what the patch
> >        does. "Fixes #NNNN" is not an adequate commit message.
> >
> >      * changes should be commented where necessary (my usual rule of
> >        thumb is "write the comment you would have liked to read when you
> >        started writing your patch"). We should mention the Note
> >        convention.
> >
> >      * commit messages and comments should refer to ticket numbers where
> >        appropriate (e.g. using usual #NNNN syntax; people often get this
> >        wrong).
> >
> >      * commits should be either squashed or logically distinct,
> >        individually buildable changes.
> >
> >      * changes to most of `base` need to go through the CLC (this may be
> >        optional as defining what set of `base` this applies to is a bit
> >        tricky; in the interest of keeping things concise we may be
> >        better off handling this personally on a case-by-case basis)
> >
> >      * code changes should conform to GHC's (somewhat fluid, for better
> >        or worse) code style
> >        (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)
> >
> >      * thought should be given to testing
> >
> >     Having a document which succinctly summarised these expectations as
> >     we could easily refer to it during code review. Even better, we
> >     could excerpt it as a checklist in our merge request description
> >     template (I have put up an initial attempt at this as !149).
> >
> > Anyways, there is more to be said here but this email is getting a bit
> > long so let's leave it for future discussions.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Contributing
>
>
>
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> --
> Tobias Dammers - tdammers at gmail.com
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From tdammers at gmail.com  Thu Jan 31 16:04:54 2019
From: tdammers at gmail.com (Tobias Dammers)
Date: Thu, 31 Jan 2019 17:04:54 +0100
Subject: Thoughts on the Contributing page
In-Reply-To: <CALuQ0m8Zy-ojfDQKF+QS=8cw=Z_m2XUfM2uXjBLzVTTun=rQHg@mail.gmail.com>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190131154823.gf6wzwgj7yvhunmt@nibbler>
 <CALuQ0m8Zy-ojfDQKF+QS=8cw=Z_m2XUfM2uXjBLzVTTun=rQHg@mail.gmail.com>
Message-ID: <20190131160452.zagyhlwpa4v7pffl@nibbler>

On Thu, Jan 31, 2019 at 03:57:20PM +0000, Matthew Pickering wrote:
> I think you should suggest cloning the main ghc repo and adding the
> fork as a remote. This is the usual github workflow.

And by "the main ghc repo", I take it you mean the gitlab one?

> 
> On Thu, Jan 31, 2019 at 3:48 PM Tobias Dammers <tdammers at gmail.com> wrote:
> >
> > One more thing I noticed: the current Newcomers instructions say to
> > clone git://github.com/ghc/ghc, but if you're going to use the
> > gitlab-based MR workflow later on, cloning the gitlab repo directly is
> > going to be a lot more convenient. And then there's also
> > git.haskell.org, which is what I've been using so far.
> >
> > So which one of these should we tell people to clone? I'm inclined to
> > recommend the following workflow:
> >
> > 1. Create gitlab account as needed
> > 2. Fork the GHC project
> > 3. Clone your fork from gitlab
> > 4. Create feature branch
> > 5. Make changes, squash, validate, rebase, push to fork
> > 6. Create MR on gitlab
> >
> > This would keep the hassle to a minimum for a new contributor, and does
> > not require push permissions on `ghc/ghc`.
> >
> > On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> > >
> > >
> > > For those following along at home:
> > >
> > >    David has been looking at revising our contributor documentation.
> > >    He has started consolidating a variety of relevant content on the
> > >    Contributing page of the Wiki [1]. Below are my thoughts; feel free
> > >    to chime in with your own.
> > >
> > >
> > > David,
> > >
> > > The contributing page is looking quite good. However, I do wonder
> > > whether we could reduce the link "fan-out" a bit more: it still rather
> > > feels like a collection of links with no clear "beginning".
> > >
> > > The "Newcomers to GHC" section is a great start but I see two
> > > potential issues:
> > >
> > >  * we don't clearly articulate the precise steps that a newcomer will
> > >    need to take
> > >
> > >  * the first thing we mention are four links which, while useful,
> > >    constitute a significant volume of reading for a newcomer.
> > >    I fear we may lose people at this point.
> > >
> > > Regarding the second point, I think that WorkingConventions/FixingBugs is a
> > > good model in that it clearly lists a series of concrete steps that the
> > > contributor should take. Admittedly, I think some of the detail should
> > > be dropped or moved (e.g. the mention of setting git's user.name
> > > variable is likely unnecessary in 2019).
> > >
> > > I think that something similar to this list should be the first thing
> > > one sees when they reach the contributing page. Ideally the "typical"
> > > case of a new contributor wanting to submit their first patch would be
> > > able to gather everything they need to get started in one or two
> > > screenfuls of text. After that prose can come additional links to
> > > more in-depth documentation.
> > >
> > > Other various issues I noticed:
> > >
> > >  * We link to wiki:WorkingConventions from a variety of places
> > >    (including wiki:Contributing) but it is now just a link to
> > >    wiki:Contributing.
> > >
> > >  * wiki:WorkingConventions/FixingBugs still has references to
> > >    Phabricator. In general we should start culling such references.
> > >
> > >  * wiki:WorkingConventions/FixingBugs also has references to Trac
> > >    documentation. We should try to replace these with the relevant
> > >    GitLab documentation when we migrate.
> > >
> > >  * wiki:WorkingConventions/FixingBugs should be updated to reflect
> > >    that GitLab CI is now the source of truth for validation.
> > >
> > >  * I don't know exactly how this should look but I think we need to do a
> > >    better job of concisely stating what we expect of contributions. That
> > >    is:
> > >
> > >      * commit messages should be readable and discuss what the patch
> > >        does. "Fixes #NNNN" is not an adequate commit message.
> > >
> > >      * changes should be commented where necessary (my usual rule of
> > >        thumb is "write the comment you would have liked to read when you
> > >        started writing your patch"). We should mention the Note
> > >        convention.
> > >
> > >      * commit messages and comments should refer to ticket numbers where
> > >        appropriate (e.g. using usual #NNNN syntax; people often get this
> > >        wrong).
> > >
> > >      * commits should be either squashed or logically distinct,
> > >        individually buildable changes.
> > >
> > >      * changes to most of `base` need to go through the CLC (this may be
> > >        optional as defining what set of `base` this applies to is a bit
> > >        tricky; in the interest of keeping things concise we may be
> > >        better off handling this personally on a case-by-case basis)
> > >
> > >      * code changes should conform to GHC's (somewhat fluid, for better
> > >        or worse) code style
> > >        (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)
> > >
> > >      * thought should be given to testing
> > >
> > >     Having a document which succinctly summarised these expectations as
> > >     we could easily refer to it during code review. Even better, we
> > >     could excerpt it as a checklist in our merge request description
> > >     template (I have put up an initial attempt at this as !149).
> > >
> > > Anyways, there is more to be said here but this email is getting a bit
> > > long so let's leave it for future discussions.
> > >
> > > Cheers,
> > >
> > > - Ben
> > >
> > >
> > > [1] https://ghc.haskell.org/trac/ghc/wiki/Contributing
> >
> >
> >
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > --
> > Tobias Dammers - tdammers at gmail.com
> > _______________________________________________
> > 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

-- 
Tobias Dammers - tdammers at gmail.com

From matthewtpickering at gmail.com  Thu Jan 31 16:22:33 2019
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 31 Jan 2019 16:22:33 +0000
Subject: Thoughts on the Contributing page
In-Reply-To: <20190131160452.zagyhlwpa4v7pffl@nibbler>
References: <875zuke5az.fsf@smart-cactus.org>
 <20190131154823.gf6wzwgj7yvhunmt@nibbler>
 <CALuQ0m8Zy-ojfDQKF+QS=8cw=Z_m2XUfM2uXjBLzVTTun=rQHg@mail.gmail.com>
 <20190131160452.zagyhlwpa4v7pffl@nibbler>
Message-ID: <CALuQ0m9BGa-hO8Ai5sT1gb0-wd0Yisi=DkRPhk454E2qJdu2Eg@mail.gmail.com>

Yes, clone from https://gitlab.haskell.org/ghc/ghc.git

Then submodules will work out properly as well.

Matt

On Thu, Jan 31, 2019 at 4:05 PM Tobias Dammers <tdammers at gmail.com> wrote:
>
> On Thu, Jan 31, 2019 at 03:57:20PM +0000, Matthew Pickering wrote:
> > I think you should suggest cloning the main ghc repo and adding the
> > fork as a remote. This is the usual github workflow.
>
> And by "the main ghc repo", I take it you mean the gitlab one?
>
> >
> > On Thu, Jan 31, 2019 at 3:48 PM Tobias Dammers <tdammers at gmail.com> wrote:
> > >
> > > One more thing I noticed: the current Newcomers instructions say to
> > > clone git://github.com/ghc/ghc, but if you're going to use the
> > > gitlab-based MR workflow later on, cloning the gitlab repo directly is
> > > going to be a lot more convenient. And then there's also
> > > git.haskell.org, which is what I've been using so far.
> > >
> > > So which one of these should we tell people to clone? I'm inclined to
> > > recommend the following workflow:
> > >
> > > 1. Create gitlab account as needed
> > > 2. Fork the GHC project
> > > 3. Clone your fork from gitlab
> > > 4. Create feature branch
> > > 5. Make changes, squash, validate, rebase, push to fork
> > > 6. Create MR on gitlab
> > >
> > > This would keep the hassle to a minimum for a new contributor, and does
> > > not require push permissions on `ghc/ghc`.
> > >
> > > On Sat, Jan 19, 2019 at 03:55:06PM -0500, Ben Gamari wrote:
> > > >
> > > >
> > > > For those following along at home:
> > > >
> > > >    David has been looking at revising our contributor documentation.
> > > >    He has started consolidating a variety of relevant content on the
> > > >    Contributing page of the Wiki [1]. Below are my thoughts; feel free
> > > >    to chime in with your own.
> > > >
> > > >
> > > > David,
> > > >
> > > > The contributing page is looking quite good. However, I do wonder
> > > > whether we could reduce the link "fan-out" a bit more: it still rather
> > > > feels like a collection of links with no clear "beginning".
> > > >
> > > > The "Newcomers to GHC" section is a great start but I see two
> > > > potential issues:
> > > >
> > > >  * we don't clearly articulate the precise steps that a newcomer will
> > > >    need to take
> > > >
> > > >  * the first thing we mention are four links which, while useful,
> > > >    constitute a significant volume of reading for a newcomer.
> > > >    I fear we may lose people at this point.
> > > >
> > > > Regarding the second point, I think that WorkingConventions/FixingBugs is a
> > > > good model in that it clearly lists a series of concrete steps that the
> > > > contributor should take. Admittedly, I think some of the detail should
> > > > be dropped or moved (e.g. the mention of setting git's user.name
> > > > variable is likely unnecessary in 2019).
> > > >
> > > > I think that something similar to this list should be the first thing
> > > > one sees when they reach the contributing page. Ideally the "typical"
> > > > case of a new contributor wanting to submit their first patch would be
> > > > able to gather everything they need to get started in one or two
> > > > screenfuls of text. After that prose can come additional links to
> > > > more in-depth documentation.
> > > >
> > > > Other various issues I noticed:
> > > >
> > > >  * We link to wiki:WorkingConventions from a variety of places
> > > >    (including wiki:Contributing) but it is now just a link to
> > > >    wiki:Contributing.
> > > >
> > > >  * wiki:WorkingConventions/FixingBugs still has references to
> > > >    Phabricator. In general we should start culling such references.
> > > >
> > > >  * wiki:WorkingConventions/FixingBugs also has references to Trac
> > > >    documentation. We should try to replace these with the relevant
> > > >    GitLab documentation when we migrate.
> > > >
> > > >  * wiki:WorkingConventions/FixingBugs should be updated to reflect
> > > >    that GitLab CI is now the source of truth for validation.
> > > >
> > > >  * I don't know exactly how this should look but I think we need to do a
> > > >    better job of concisely stating what we expect of contributions. That
> > > >    is:
> > > >
> > > >      * commit messages should be readable and discuss what the patch
> > > >        does. "Fixes #NNNN" is not an adequate commit message.
> > > >
> > > >      * changes should be commented where necessary (my usual rule of
> > > >        thumb is "write the comment you would have liked to read when you
> > > >        started writing your patch"). We should mention the Note
> > > >        convention.
> > > >
> > > >      * commit messages and comments should refer to ticket numbers where
> > > >        appropriate (e.g. using usual #NNNN syntax; people often get this
> > > >        wrong).
> > > >
> > > >      * commits should be either squashed or logically distinct,
> > > >        individually buildable changes.
> > > >
> > > >      * changes to most of `base` need to go through the CLC (this may be
> > > >        optional as defining what set of `base` this applies to is a bit
> > > >        tricky; in the interest of keeping things concise we may be
> > > >        better off handling this personally on a case-by-case basis)
> > > >
> > > >      * code changes should conform to GHC's (somewhat fluid, for better
> > > >        or worse) code style
> > > >        (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)
> > > >
> > > >      * thought should be given to testing
> > > >
> > > >     Having a document which succinctly summarised these expectations as
> > > >     we could easily refer to it during code review. Even better, we
> > > >     could excerpt it as a checklist in our merge request description
> > > >     template (I have put up an initial attempt at this as !149).
> > > >
> > > > Anyways, there is more to be said here but this email is getting a bit
> > > > long so let's leave it for future discussions.
> > > >
> > > > Cheers,
> > > >
> > > > - Ben
> > > >
> > > >
> > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Contributing
> > >
> > >
> > >
> > > > _______________________________________________
> > > > ghc-devs mailing list
> > > > ghc-devs at haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > >
> > >
> > > --
> > > Tobias Dammers - tdammers at gmail.com
> > > _______________________________________________
> > > 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
>
> --
> Tobias Dammers - tdammers at gmail.com
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs