- ghc-devs - Haskell.org

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

Hi Brandon, Could you show the code? I have no idea how indexed monads could possibly be related here. All I want is to have a type class that unifies these two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Cheers, Andrey From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 30 May 2019 22:32 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: Artem Pelenitsyn <a.pelenitsyn(a)gmail.com>; Andreas Klebinger <klebinger.andreas(a)gmx.at>; ghc-devs(a)haskell.org Subject: Re: Container type classes They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi Artem, Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com<mailto:a.pelenitsyn@gmail.com>] Sent: 30 May 2019 20:56 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Andreas Klebinger <klebinger.andreas(a)gmx.at<mailto:klebinger.andreas@gmx.at>> Subject: Re: Container type classes Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b(a)gmail.com<mailto:allbery.b@gmail.com>

2 1

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

Hi Artem, Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com] Sent: 30 May 2019 20:56 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> Subject: Re: Container type classes Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 2

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey

3 2

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

> If you care about performance then explicit dictionary passing is > going to be worse than using type classes. Of course! But explicit dictionary passing works great for tests: the code size is reduced from O(#modules * #tests) when using the module system to O(#modules + #tests) when using dictionaries. For example, in the algebraic-graphs library, I have 500+ generic tests and around 10 modules. I don't want to write 5000 tests! Here is an example generic test which uses explicit dictionary passing: https://github.com/snowleopard/alga/blob/master/test/Algebra/Graph/Test/Gen…. I don't think it would be possible to reuse this test for different graph data types by using the module system instead of dictionaries. (Perhaps, Backpack could help? I don't know it very well.) Cheers, Andrey -----Original Message----- From: Matthew Pickering [mailto:matthewtpickering@gmail.com] Sent: 30 May 2019 18:26 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> Subject: Re: Container type classes If you care about performance then explicit dictionary passing is going to be worse than using type classes. At that point though, what do you gain from using the module system as you are just going to pass the same dictionaries into every function and never change them. So, for me, keep using modules but make the APIs of each module more consistent if you think it's worthwhile. On Thu, May 30, 2019 at 6:11 PM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > > Hi all, > > I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > > However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

[hadrian/windows] build broken
by Shayne Fletcher 30 May '19

30 May '19

Windows builds with hadrian are currently failing with "file does not exist and no build rule available" `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas on how to overcome that? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

4 17

Two weeks left for Haskell Exchange talk proposals
by Spiwack, Arnaud 29 May '19

29 May '19

Dear all, Only two weeks remain before the end of the Haskell eXchange call-for-paper (11th of june). Send your proposals! This year's keynote speaker will be Elise Huard, Gabriele Keller, Simon Peyton Jones, and Philip Wadler. Find the full CFP and submit your proposal here: https://docs.google.com/forms/d/e/1FAIpQLSeJgeTqAdYLBlRcO9PDzI3yrR22CqzhInH…

1 0

RE: Clean build fails with make
by Simon Peyton Jones 29 May '19

29 May '19

| Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. Excellent, that works. | I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. It may not matter. We don't want to spend lots of time on the old build system. Is this a once-only thing? I.e. once done will never happen again? Or might it happen repeatedly? Simon | -----Original Message----- | From: John Ericson <git(a)johnericson.me> | Sent: 28 May 2019 23:33 | To: Ben Gamari <ben(a)well-typed.com> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; GHC developers <ghc- | devs(a)haskell.org> | Subject: Re: Clean build fails with make | | This is the same issue as before; and I don't know how the cleaning works. | The good thing is that I think I am done adding things to that. (Perhaps | some should be removed, but that won't cause these issues.) | | Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. | | Sorry for more disruption, | | John | | On Tue, May 28, 2019, at 5:56 PM, Ben Gamari wrote: | > Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | > > A 'sh validate` in a clean tree fails as below. | > > Is that expected? That is, is validate dead? | > > If so let's change the shell script to say "game over, just use | > > Hadrian". | > > Simon | > | > John, it looks like this is more fallout from the recent platform | > changes. Any thoughts? | > | > Cheers, | > | > - Ben | > | > > "inplace/bin/ghc-cabal" check libraries/ghc-prim | > > | > > "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install | > > --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" | > > --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" | > > --disable-library-for-ghci --enable-library-vanilla | > > --enable-library-for-ghci --disable-library-profiling --enable-shared | --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno- | error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" | > > " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno- | error=inline " --with-gcc="gcc" | > > --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with- | happy="/usr/bin/happy" | > > | > > Configuring ghc-prim-0.6.1... | > > | > > ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited | > > with an | > > | > > error: | > > | > > No entry for "target platform string" in | > > | > > "/home/simonpj/code/HEAD/inplace/lib/settings" | > > | > > libraries/ghc-prim/ghc.mk:4: recipe for target | > > 'libraries/ghc-prim/dist-install/package-data.mk' failed | > > | > > make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error | > > 1 | > > | > > Makefile:123: recipe for target 'all' failed | > > | > > make: *** [all] Error 2 | > | > | > *Attachments:* | > * signature.asc

1 0

Clean build fails with make
by Simon Peyton Jones 28 May '19

28 May '19

A 'sh validate` in a clean tree fails as below. Is that expected? That is, is validate dead? If so let's change the shell script to say "game over, just use Hadrian". Simon "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an error: No entry for "target platform string" in "/home/simonpj/code/HEAD/inplace/lib/settings" libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2

2 1

RE: newtype workers
by Simon Peyton Jones 28 May '19

28 May '19

| I'm working on unlifted newtypes. | | In MkId.mkDataConWorkId, I see | | > mkDataConWorkId wkr_name data_con | > | isNewTyCon tycon | > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info | > | otherwise | > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty alg_wkr_info | | Why is a newtype worker called a wrapper (DataConWrapId)? Note that some | newtype constructors have separate wrappers (which is relatively new). | This doesn't appear to be hurting anything right now, but it's odd, and | there's no commentary on this. That is indeed odd, I agree. Some points * Newtypes can have wrappers: see Note [Data con wrappers and GADT syntax] in MkId.hs * The "worker" for a newtype data constructor is just a function with a compulsory unfolding, of form (\x. x |> co), where co is the newtype coercion. * I agree that it's not right to describe the "worker" for a newtype data constructor as a "DataConWrapId"; after all, it may have a wrapper too (see previous bullet). * Bu not is it rigt to call it a regular DataConWorkId. Those are *data* constructors, head normal forms, very very special. The kosher thing would be to create a NewtypeWorkId. But that's seems a terrible fiddle, because these things are inlined compulsorily so they never exist for long. Maybe it should just be a vanilla Id. While there are a few places where we do test for data-con-wrap-ids -- eg in isImplicitId -- but remember that these things are inlined so aggressively that we will only see them very briefly. Or leave it as-is, with the above commentary as a Note -- that might be the easiest thing! Might you make a little patch? Simon | -----Original Message----- | From: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Sent: 25 May 2019 11:50 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: newtype workers | | Hi Simon, | | I'm working on unlifted newtypes. | | In MkId.mkDataConWorkId, I see | | > mkDataConWorkId wkr_name data_con | > | isNewTyCon tycon | > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info | > | otherwise | > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty alg_wkr_info | | Why is a newtype worker called a wrapper (DataConWrapId)? Note that some | newtype constructors have separate wrappers (which is relatively new). | This doesn't appear to be hurting anything right now, but it's odd, and | there's no commentary on this. | | Thanks, | Richard

1 0

Re: Processing MRs very slow?
by David Eichmann 28 May '19

28 May '19

Simon, your suggestion makes sense to me. We can have 3 pages that cover: 1. Fixing Bugs (/working-conventions/fixing-bugs) 2. Adding Features (/working-conventions/adding-features) 3. Merge request work-flow (New page e.g. (/working-conventions/merge-requests) Then (1) and (2) would reference (3) and most of the content in /home would be moved to (3). This leave one loose end: /home is left almost empty. I suggest we move contents of /contributing <https://gitlab.haskell.org/ghc/ghc/wikis/contributing> to /home, though I'm interested in hearing any alternative idea - David E On 5/23/19 12:24 PM, Simon Peyton Jones wrote: > > Thanks > > * I've noted this infixing-bugs <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> and linked tohome <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-… <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> andhttps://gitlab.haskell.org/ghc/ghc/wikis/home <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>) > > I agree with avoiding duplication, but let’s fix that by fixing the > home page. Why is there all this detail about merge requests there? > Let’s push all that off into a single integrated page “How to > contribute a patch”. > > The current “how to contribute a patch” page is really “how to fix a > bug (including how to contribute a patch)”. So maybe we should have: > > * How to fix a bug > * How to add a feature > > both as pages of their own, but both pointing to a single pate > > * The mechanics of contributing a patch (bug or feature) > > That would also de-clutter the home page. > > Simon > > *From:*David Eichmann <davide(a)well-typed.com> > *Sent:* 23 May 2019 12:10 > *To:* Simon Peyton Jones <simonpj(a)microsoft.com>; Ben Gamari > <ben(a)well-typed.com> > *Cc:* iavor.diatchki(a)gmail.com > *Subject:* Re: Processing MRs very slow? > > I found the email you're referring to > https://mail.haskell.org/pipermail/ghc-devs/2019-May/017656.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask…>. > You mentioned 3 points of missing information: > > * Picking approvers > * Lets see how the "gitlab upgrade - change in approval system" email thread develops. > * Assigning to Marge > * I've noted this infixing-bugs <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> and linked tohome <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-… <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> andhttps://gitlab.haskell.org/ghc/ghc/wikis/home <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>) > * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. > * I've added some info inhttps://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> > Hope this is better now. Ben maybe you'd like to double check the bullet list inhttps://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> for the conditions under which marge will batch your MR. > - David E > > On 5/23/19 9:02 AM, Simon Peyton Jones wrote: > > | | Perhaps it is worth updating Step 7 or 8 of > > Yes, I suggested that to Ben a week or two ago, but he's flat out on incremental GC. > > Maybe David could do it? I can dig out the email. > > Thanks! > > Simon > > | -----Original Message----- > > | From: ghc-devs<ghc-devs-bounces(a)haskell.org> <mailto:ghc-devs-bounces@haskell.org> On Behalf Of Iavor Diatchki > > | Sent: 22 May 2019 23:49 > > | To: David Eichmann<davide(a)well-typed.com> <mailto:davide@well-typed.com> > > | Cc: ghc-devs<ghc-devs(a)haskell.org> <mailto:ghc-devs@haskell.org> > > | Subject: Re: Processing MRs very slow? > > | > > | Great thanks! How can I have a look at Marge-bot's queue? > > | > > | Perhaps it is worth updating Step 7 or 8 of > > |https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > > | bugs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6 > > | df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&a > > | mp;sdata=gWoMbrHZwyfDQWeCst0VmAl4x%2Fv%2BjFY3dUXI7X%2FCHEQ%3D&reserved > > | =0 > > | to indicate that the reviewers should assign the MR to Marge-bot when it > > | is approved, and how one can check if that has happened. > > | > > | > > | On Wed, May 22, 2019 at 9:53 AM David Eichmann<davide(a)well-typed.com> <mailto:davide@well-typed.com> > > | wrote: > > | > > > | > Recently there have been some issues with CI that has slowed down > > | > merging. In particular a performance test (T9630) was failing on CI. > > | > That is fixed now and as of today Marge-Bot seems to be merging MRs > > | > again. I'll continue to monitor this in the coming days. > > | > > > | > Iavor, your MR was approved but not assigned to Marge-bot, and so was > > | > not in the merge queue. I'm not sure who has permission to do this, > > | > but you can always ping the approvers. In this case I've assigned to > > | > Marge-bot for you, and it will hopefully be merge soon. > > | > > > | > David Eichmann > > | > > > | > On 5/22/19 5:09 PM, Iavor Diatchki wrote: > > | > > Hello, > > | > > > > | > > I made a gitlab MR that adds two NOINLINE pragmas and some comments. > > | > > It's been about a week since my last push to the MR, and nothing has > > | > > happened since. > > | > > > > | > > Is there a way to check on what is its status: > > | > > - Is it stuck because I need to do something? > > | > > - Is it stuck because someone else needs to do something? > > | > > - Or is it just in the queue to be merged, in which case it would > > | > > be nice to know where in line it is, so I can see that there is > > | > > progress, and it is not just stuck. > > | > > > > | > > Given that this is such a simple MR, I am not too worried about > > | > > conflicts but a week long lag seems less than ideal for anything > > | > > even mildly complex. > > | > > > > | > > -Iavor > > | > > > > | > > PS: I just clicked on all the little check boxes from the > > | > > template---perhaps that's why things weren't progressing? > > | > > _______________________________________________ > > | > > ghc-devs mailing list > > | > >ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > | > >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai > > | > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02% > > | > > 7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6df07cbb3%7C > > | > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&sd > > | > > ata=W3wnIH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reser > > | > > ved=0 > > | > > > | > -- > > | > David Eichmann, Haskell Consultant > > | > Well-Typed LLP, > > | >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w > > | > ell-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773d > > | > d4c553d8c08d6df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 > > | > 941621907873036&sdata=RIcEblo4xNED7UY6Vv%2FNIG4aAzcjLgzN8uegqX9K%2 > > | > F3I%3D&reserved=0 > > | > > > | > Registered in England & Wales, OC335890 > > | > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > > | > > > | > _______________________________________________ > > | > ghc-devs mailing list > > | >ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > | >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. > > | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01 > > | > %7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6df07cbb3%7C72f988 > > | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&sdata=W3wn > > | > IH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reserved=0 > > | _______________________________________________ > > | ghc-devs mailing list > > |ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > |https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6 > > | df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&a > > | mp;sdata=W3wnIH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reserv > > | ed=0 > > -- > David Eichmann, Haskell Consultant > Well-Typed LLP,http://www.well-typed.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

2 2