- ghc-devs - Haskell.org

RE: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in JUnit output (224fec6)
by Simon Peyton Jones 11 Feb '19

11 Feb '19

Are these commits really for #16188? For which we have a MR in progress https://gitlab.haskell.org/ghc/ghc/merge_requests/207 I was just surprised to see wip/T16188 going by. Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 10 February 2019 21:32 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in | JUnit output (224fec6) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T16188 | Link : | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fchangeset%2F224fec6983e16ecfc44a80d47e591a2425468e | af%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0d | d08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63685431128635 | 6725&sdata=ZS4Bp%2FMsebLALA27waYiWgtyx%2FyrKSkiCLcFXvSfXBE%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 224fec6983e16ecfc44a80d47e591a2425468eaf | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Thu Jan 24 14:20:11 2019 -0500 | | testsuite: Report stdout and stderr in JUnit output | | This patch makes the JUnit output more useful as now we also report | the | stdout/stderr in the message which can be used to quickly identify | why a | test is failing without downloading the log. | | This also introduces TestResult, | previously we were simply passing around tuples, making things the | implementation rather difficult to follow and harder to extend. | | | >--------------------------------------------------------------- | | 224fec6983e16ecfc44a80d47e591a2425468eaf | testsuite/driver/junit.py | 23 ++++++++-------- | testsuite/driver/testglobals.py | 15 +++++++++++ | testsuite/driver/testlib.py | 58 ++++++++++++++++++++++++++--------- | ------ | testsuite/driver/testutil.py | 7 +++-- | 4 files changed, 69 insertions(+), 34 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 224fec6983e16ecfc44a80d47e591a2425468eaf | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0dd | 08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854311286366 | 720&sdata=RH6Jnvs7cNsnGyLpwONSZ0Cldighb85HZtuWfn4Gc9Q%3D&reserved | =0

2 1

Commit comments - call for opinions
by Tobias Dammers 11 Feb '19

11 Feb '19

Dear all, So far, we had a feature in Trac where git commit messages mentioning a ticket would automatically be copied into a comment on that commit. See, for example, this comment: https://ghc.haskell.org/trac/ghc/ticket/13615#comment:47 GitLab does things slightly differently. It has "live" git repository information available, and rather than the relatively static comment list we see in Trac, it synthesizes a "timeline" style list of events relevant to an issue, which includes comments ("notes"), but also issue status updates, git commits, and other things. So when a commit mentions a GitLab issue, then GitLab will insert a link to that commit into the issue's event timeline. This means that in principle, copying commit messages into notes would be redundant, and we initially decided to ignore commit comments during the Trac/GitLab migration. However, it also means that the issue timeline will no longer display the actual commit message anymore, just a link to the commit ("@username mentioned this issue in commit 1234beef" or similar). So what used to be a narrative that you could read top-down to retrace the issue's history is now a bit more scattered. Now, the ideal solution would be for GitLab to instead display the full commit message, but I don't see this happening anytime soon, because it would require a patch to GitLab itself. So we're left with two options: a) Import commit comments as notes, duplicating the commit message into the note, and having both the full commit note and a hyperlinked commit reference in the issue timeline. b) Don't import commit comments as notes, just rely on GitLab to insert the hyperlinked commit reference. If any of you have any preference either way, please do tell. Thanks! -- Tobias Dammers - tdammers(a)gmail.com

5 5

Memory ordering and thunk update
by Ben Gamari 10 Feb '19

10 Feb '19

Hi Simon and Peter, I just wanted to draw your attention to !337 [1], where I try to fix #15994. While it's possible I have missed something, it looks to me like there has been a bug lurking here for quite some time. In particular on a weak memory model machine we do not place a write barrier between the construction of the result of a thunk evaluation and making the results visible to other cores via the indirection's indirectee field. This essentially means that a thread looking at the indirectee may essentially see uninitialized memory. Specifically, updateWithIndirection is currently: # Evaluation result p2 initialized by caller ... ((StgInd *)p1)->indirectee = p2; write_barrier(); SET_INFO(p1, &stg_BLACKHOLE_info); ... whereas I think this should rather be # Evaluation result p2 initialized by caller ... write_barrier(); ((StgInd *)p1)->indirectee = p2; SET_INFO(p1, &stg_BLACKHOLE_info); ... I describe the reasoning for this in more detail in the Note added in !337. All-in-all, I'm rather surprised to find this bug. While we won't see this issue manifest on x86_64 due to this architecture's memory model, we have long supported ARM, PowerPC, and SPARC, all of which have weakly-ordered execution modes. I can't find any relevant open tickets from these platforms. The fact that this wasn't noticed on these platforms makes me wonder whether I am just missing something. Let me know what you think. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/337

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Good to hear you managed to build GHC both with Make and Hadrian. Best wishes with your first GHC patch! Cheers, Andrey From: Eric Crockett [mailto:ecrockett0@gmail.com] Sent: 09 February 2019 18:21 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: Re: Cannot build with Hadrian Andrey, I had already deleted the folder and tried again with make, which was successful. But since I sent the email, I figured I'd try again with hadrian as well. I followed exactly what I did above (which is what I did the first time, too) and it worked fine. *shrug* Thanks anyway! Eric On Sat, Feb 9, 2019 at 5:03 AM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com<mailto:ecrockett0@gmail.com>> To: ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com<mailto:KBdwgb1mLAWgiCsJok6unVhchY%2BuLBbTQ@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com> To: ghc-devs <ghc-devs(a)haskell.org> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

Cannot build with Hadrian
by Eric Crockett 09 Feb '19

09 Feb '19

GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities

1 0

Constructor wrappers vs workers in generated Core
by Christopher Done 08 Feb '19

08 Feb '19

Hi all, I'm compiling Haskell modules with this simple function. I'd like to interpret the Core for practical use and also educational use. compile :: GHC.GhcMonad m => GHC.ModSummary -> m GHC.ModGuts compile modSummary = do parsedModule <- GHC.parseModule modSummary typecheckedModule <- GHC.typecheckModule parsedModule desugared <- GHC.desugarModule typecheckedModule pure (GHC.dm_core_module desugared) And then I'm taking the mg_binds from ModGuts. I want to work with the simplest, least-transformed Core as possible. One thing that's a problem for me is that e.g. the constructor GHC.Integer.Type.S# in this expression \ (ds_dnHN :: Integer) -> case ds_dnHN of _ [Occ=Dead] { S# i# -> case isTrue# (># i# 1#) of _ [Occ=Dead] { False -> (\ _ [Occ=Dead, OS=OneShot] -> $WS# 2#) void#; True -> case nextPrimeWord# (int2Word# i#) of wild_Xp { __DEFAULT -> wordToInteger wild_Xp } }; Jp# bn -> $WJp# (nextPrimeBigNat bn); Jn# _ [Occ=Dead] -> $WS# 2# } is referred to by its wrapper, "$WS#". In general, I'd prefer if it Core always constructed the worker S# directly. It would reduce the number of cases I have to handle. Additionally, what if a worker gets transformed by GHC from e.g. "Wibble !(Int,Int)" to "Wibble !Int !Int", are then case alt patterns going to scrutinize this transformed two-arg version? (As documented here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DataTypes#Thelife…) So my question is: is it possible to disable this wrapper transformation of data constructors? If not it seems like I'll have no option but to handle this extra wrapper stuff, due to the case analyses. That wouldn't be the end of the world, it'd just delay me by another week or so. For strict fields in constructors I was planning on simply forcing the fields in my interpreter when a constructor becomes saturated (and thereby enabling some nice inspection capabilities), rather than generating extra wrapper code that would force the arguments. Cheers

3 5

Fwd: [Haskell] PhD studentships in FP at Bristol
by Matthew Pickering 07 Feb '19

07 Feb '19

Hi all, If there are any students considering applying for PhD programs who are also GHC hackers then Bristol could be a great option for you. Myself and Csongor are currently students here and both actively working on GHC. The programming languages group in Bristol has grown from 1 to 6 people in the last three years and is continuing to expand. Cheers, Matt ---------- Forwarded message --------- From: Meng Wang <meng.wang(a)bristol.ac.uk> Date: Thu, Feb 7, 2019 at 11:20 PM Subject: [Haskell] PhD studentships in FP at Bristol To: Haskell(a)haskell.org <Haskell(a)haskell.org>, Haskell-Cafe(a)haskell.org <Haskell-Cafe(a)haskell.org> Hi list, The programming language group at the University of Bristol is looking for up to three more PhD students in the broad area of functional programming, verification, and testing to join a very dynamic group of FP researchers. http://www.bristol.ac.uk/engineering/departments/computerscience/people/men… http://www.bristol.ac.uk/engineering/departments/computerscience/people/ste… http://www.bristol.ac.uk/engineering/departments/computerscience/people/nic… The positions are fully funded, and with additional bursaries for attending conferences. The ideal candidates will have a strong background in functional programming, especially Haskell, and an appetite for cutting-edge research. For enquiries, please email meng.wang(a)bristol.ac.uk before February 22nd. Best regards, Meng _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

1 0

How to merge your patch
by Ben Gamari 07 Feb '19

07 Feb '19

tl;dr. Our beloved @marge-bot is behaving much more reliably now thanks to improvements in CI reliability and build batching. To merge an (accepted) merge request simply designate @marge-bot as its assignee. Marge will handle the rest. If things go awry let me know. Hi everyone, As you may have noticed, over the last weeks we have been feeling out how best to leverage our new CI infrastructure, particularly when it comes to merging patches. As mentioned a few weeks ago, we have introduced a bot, Marge, to help us work around some temporary limitations of GitLab's merge workflow. Unfortunately, Marge had her own set of quirks which have taken a while to sort out. In particular, fragile tests tended to result in repeated merge attempts which tended to clog up CI, leading to an avalanche of waiting, build failures, and general despair. However, we have been working to improve this situation in three ways: * provisioning more builder capacity to reduce wait times * fixing or disabling fragile tests to reduce the need for retries * enable Marge's batched merge functionality, reducing the number of builds necessary per merged patch [1] In light of this I just wanted to reiterate the previous guidance on merging patches. If you have a merge request you would like to merge simply do the following: 1. make sure that it has at least one approval. This should happen in the course of code review but do ping if this was forgotten. 2. assign the merge request to @marge-bot using the assignee field in the right-hand sidebar of the merge request page. 3. next time Marge does a batch of merges she will fold in your MR (leaving a helpful comment to let you know) and, if the batch passes CI, merge it. If not she will leave a comment letting you know there was an issue. I will try to step in to sort out the mess when this happens. Do let me know if you have any questions. Cheers, - Ben [1] thanks to Matthew Pickering for picking this up

3 6

Scaling back CI (for now)?
by Matthew Pickering 07 Feb '19

07 Feb '19

Hi all, Everyone has probably noticed that getting anything merged is a real effort at the moment. The main problem is that CI takes in the region of 5-7 hours and then spuriously fails at the end. After 5-7 hours you have to rebase and run CI again and so on. Therefore I propose to run just these four jobs on every MR: validate-x86_64-linux-deb9 validate-x86_64-linux-deb8-hadrian validate-x86_64-windows validate-x86_64-darwin The reasoning is as follows: validate-x86_64-linux-deb9 validate-x86_64-linux-deb8-hadrian These run first and are reliable and finish within an hour. Then we have lots of less reliable, lower priority jobs. Two windows jobs which take forever to run. validate-x86_64-windows validate-x86_64-windows-hadrian One darwin job validate-x86_64-darwin Many more linux jobs validate-x86_64-linux-deb9-unreg validate-x86_64-linux-deb9-integer-simple validate-x86_64-linux-fedora27 validate-x86_64-linux-deb9-llvm validate-x86_64-linux-deb8 validate-i386-linux-deb9 validate-aarch64-linux-deb9 So I don't argue that these are important to test but at the moment they produce too much friction on every commit through a combination of lack of resources and taking too long. Further to this, we really don't need to test fedora27, deb9 and deb8 for every build. When was the last time we broke one of these platforms but not the other, it's rare! So the concrete proposal is to slim back the per commit validation to four jobs. validate-x86_64-linux-deb9 validate-x86_64-linux-deb8-hadrian validate-x86_64-windows validate-x86_64-darwin which will test on the three major platforms. All the other flavours should be run once the commit reaches master. Thoughts? Cheers, Matt

5 7