- ghc-devs - Haskell.org

Updating Haddock submodule
by Simon Peyton Jones 17 Jul '14

17 Jul '14

Herbert, Austin I've just made a change to GHC that has a (trivial) knock-on effect in Haddock, so I had to update the submodule. Here is what I did, after consulting Austin. Can I humbly implore you both (or someone) to write down the workflow so that git-naïve people like me can do this with confidence, rather than (as now) in fear? Below is my draft of the workflow. It seems pretty complicated, and there are three places (in red) where I am unsure what to do. Please in writing the workflow, document every step as I have done below. Thanks! Simon 1. Starting point: · all changes made in GHC and in utils/haddock. · validate works 2. cd utils/haddock 3. git stash Keep my changes out of the way 4. git branch -av Keep the output 5. git checkout master Why 'master'? Because I know from talking to Austin that the ghc repo tracks Haddock's master branch. There is no way to get this information without talking to Someone Who Knows. There should be a wiki page that documents it. 6. Check that in the output of step 4, the current branch (which should be detatched-head) is the same commit as origin/master. I have no idea what to do if this isn't the case. 7. git pull Now Haddock's 'master' is up to date 8. git stash pop Apply the changes to the Haddock master branch 9. git add/commit to record and commit the patch as usual 10. git push Phew! At this stage we have updated Haddock. I think. 11. cd ../.. Back into main ghc repo 12. git add/commit to record patch as usual, but · include utils/haddock in the "files" you add. This will update the submodule pointer in the ghc repo · include the word "submodule" in the commit message 13. git push At this stage we have updated GHC too 14. ???? to get utils/haddock back into the detached-head state. How do I do this? git submodule update doesn't

6 8

7.8.3 source tarball imminent
by Austin Seipp 16 Jul '14

16 Jul '14

Hello *, The 7.8.3 source tarball is imminent. I'll be creating it as soon as my build is done. I expect it will take an hour or so to finish. Note that I have not yet pushed the tag (which will mark the official release version), but everything should be just fine. I'm simply a bit paranoid and running everything through its steps again before handing it out. Gabor, Luke, Mark, Karel - you know what to do when it's here. As usual, I'll be taking care of Windows and the matrix of Linux builds. Mark has stepped up to build the OS X release, for which I'm quite grateful. Sorry for the wait everyone, but it's here, and it's looking good.... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

7 9

updated OS X 7.8.3 bindist
by Mark Lentczner 16 Jul '14

16 Jul '14

The release 7.8.3 bindist for OS X was flawed: It was not build SplitObjs. That is my fault for not catching it before releasing it. You may demand a beer from me at ICFP as restitution.... I have built a new 7.8.3 bindist for OS X, and tested in 10.9, 10.7, and 10.6(!). It is SplitObjs, and still performs better than the gcc based build. Find it here: ghc-7.8.3-x86_64-apple-darwin-r2.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.8.3-x86_64-apple-darwin-r2.ta…> shasum -a 256: 7f056a48de5158a950e49f208d1e79c6721c2a908db55f7691f7695171c63306 Updated blurb for the release page: This is a bindist for Mac OS X, 10.6 or later. The package requires the command line tools package of Xcode 4 or XCode 5 to be installed. You can find Xcode at http://developer.apple.com/. If you are installing on a gcc based system (gcc --version doesn't not include the word "clang"), then then when installing this, use the command make install CC_CLANG_BACKEND=0). - Mark

1 1

Travis now tests ghc directly
by Joachim Breitner 16 Jul '14

16 Jul '14

Hi, I just added a .travis.yml file to GHC master. This means that every push will be validated automatic and for free by travis; you can check the build status at https://travis-ci.org/ghc/ghc/builds It is not a full validation. In particular, * it skips DPH * it does not build dynamic libraries and no dynamic executables * does not build haddock or generate documentation * only runs fast tests, and no performance tests This way we stay under the 50 minuite limit. Failures are reported to me, and I’ll manually report relevant breakage to you. It is also configured to mail to ghc-builds(a)haskell.org, but I don’t see these messages there. Maybe some mailing list admin needs to whitelist mails from Travis CI <notifications(a)travis-ci.org>? I’ve also added a link to it from http://ghc.haskell.org/trac/ghc/, including a nice icon showing the current build status. If you have that .travis.yml file in your branch, travis will also test these. My unofficial ghc-complete repository is therefore obsolete, I stopped updating it. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 7

7.8.1 plan
by Austin Seipp 16 Jul '14

16 Jul '14

Hello all, As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so. Second, there are just two things I want to note: - For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug. - Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night. In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist. Anyway, the time is finally here, so let's get it over with! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

16 41

Re: Windows breakage -- again
by Johan Tibell 16 Jul '14

16 Jul '14

I'll be out until Tuesday. I would much appreciate if someone with a Windows setup could help me debug this. These symbols are supposed to be defined by GCC somewhere (as GCC is outputting these when it cannot convert __sync_fetch_and_add into assembly instructions.) On Wed, Jul 16, 2014 at 9:08 PM, Niklas Larsson <metaniklas(a)gmail.com> wrote: > Oh, wait, it isn't the system linker that is complaining, it's the ghc rts > linker. Maybe we just have to tell it to leave those symbols alone. > > Niklas > > > 2014-07-16 20:57 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: > > I get the same failure when I try to build HEAD. Turns out the error >> occurs on the 32-bit Windows build, and my successful build was a 64-bit >> build. My 64-bit build still succeeds. >> >> Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. >> >> Niklas >> >> >> >> 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: >> >> I have built ghc on windows after that was added with no issue. >>> >>> I can take a look this evening and see how HEAD works for me. >>> >>> The standard gcc in the tarballs is 4.6.3, which is getting long in the >>> tooth, there is an issue on trac to upgrade it. >>> >>> -- Niklas >>> >>> ------------------------------ >>> Från: Johan Tibell <johan.tibell(a)gmail.com> >>> Skickat: ‎2014-‎07-‎16 09:57 >>> Till: Simon Peyton Jones <simonpj(a)microsoft.com> >>> Kopia: ghc-devs(a)haskell.org >>> Ämne: Re: Windows breakage -- again >>> >>> You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) >>> and push that to the repo if you wish. I will try to re-add the primop >>> again after I figure out what's wrong. >>> >>> >>> On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> >>> wrote: >>> >>>> I added some primops about a month ago >>>> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, >>>> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual >>>> [1] says: >>>> >>>> > " Not all operations are supported by all target processors. If a >>>> particular operation cannot be implemented on the target processor, a >>>> warning will be generated and a call an external function will be >>>> generated. The external function will carry the same name as the builtin, >>>> with an additional suffix `_n' where n is the size of the data type." >>>> >>>> I'm a bit surprised by this error for two reasons: >>>> >>>> * A call to that symbol should only be generated if the CPU doesn't >>>> support the atomic instructions. What CPU model does Windows report that >>>> you have? >>>> >>>> * gcc should define such a symbol. For me the following test program >>>> compiles: >>>> >>>> #include <stdint.h> >>>> >>>> uint8_t test(uint8_t* ptr, uint8_t val) { >>>> return __sync_fetch_and_add_1(ptr, val); >>>> } >>>> >>>> int main(void) { >>>> uint8_t n; >>>> return test(&n, 1); >>>> } >>>> >>>> Does that compile for you? Which version of GCC do we end up using on >>>> Windows? >>>> >>>> The reported symbol (___sync_fetch_and_add_1) has three leading >>>> underscores, that looks weird. Can you compile just >>>> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates >>>> a reference to that symbol? >>>> >>>> 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >>>> >>>> >>>> On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones < >>>> simonpj(a)microsoft.com> wrote: >>>> >>>>> Aargh! The Windows build has broken – again. I can’t build GHC on >>>>> my laptop any more. >>>>> >>>>> A clean ‘sh validate’ finishes as below. What on earth is >>>>> `___sync_fetch_and_add_1'? >>>>> >>>>> Can anyone help? Thanks! >>>>> >>>>> Simon >>>>> >>>>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static >>>>> -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 >>>>> -hide-all-packages -i -ilibraries/vector/. >>>>> -ilibraries/vector/dist-install/build >>>>> -ilibraries/vector/dist-install/build/autogen >>>>> -Ilibraries/vector/dist-install/build >>>>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include >>>>> -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include >>>>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package >>>>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package >>>>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O >>>>> -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts >>>>> -Wwarn -odir libraries/vector/dist-install/build -hidir >>>>> libraries/vector/dist-install/build -stubdir >>>>> libraries/vector/dist-install/build -c >>>>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o >>>>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o >>>>> >>>>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to >>>>> load package `ghc-prim' >>>>> >>>>> ghc-stage2.exe: >>>>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: >>>>> unknown symbol `___sync_fetch_and_add_1' >>>>> >>>>> libraries/vector/ghc.mk:5: recipe for target >>>>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' >>>>> failed >>>>> >>>>> make[1]: *** >>>>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] >>>>> Error 1 >>>>> >>>>> >>>>> >>>>> I >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> >

1 0

Windows breakage -- again
by Simon Peyton Jones 16 Jul '14

16 Jul '14

Aargh! The Windows build has broken - again. I can't build GHC on my laptop any more. A clean 'sh validate' finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I

3 6

another Phab question: Local commits
by Richard Eisenberg 16 Jul '14

16 Jul '14

Hi all, I wanted to make a comment in a Phab revision and refer to performance of a particular commit. So, I found the "Local commits" section of my page (https://phabricator.haskell.org/D73) But, those SHA's ("Commit" and "Tree") seem not to be related to others. The correct SHA, as I can see it, is the bit after "rGHC" in the "Description" field of "Diff 2". That SHA corresponds to the SHA I have on my own machine. What are the "Local commit" SHA's? Is there a way to refer to a particular commit in a Phab comment? And, while I'm at it, why do I have *2* Diffs here? I submitted only one git commit. One of the diffs (#2 a.k.a. #161 -- there seem to be two numbering schemes) is empty. Many thanks! Richard

1 0

SV: Windows breakage -- again
by Niklas Larsson 16 Jul '14

16 Jul '14

I have built ghc on windows after that was added with no issue. I can take a look this evening and see how HEAD works for me. The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth, there is an issue on trac to upgrade it. -- Niklas ----- Ursprungligt meddelande ----- Från: "Johan Tibell" <johan.tibell(a)gmail.com> Skickat: ‎2014-‎07-‎16 09:57 Till: "Simon Peyton Jones" <simonpj(a)microsoft.com> Kopia: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: Re: Windows breakage -- again You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you wish. I will try to re-add the primop again after I figure out what's wrong. On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: I added some primops about a month ago (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1] says: > " Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." I'm a bit surprised by this error for two reasons: * A call to that symbol should only be generated if the CPU doesn't support the atomic instructions. What CPU model does Windows report that you have? * gcc should define such a symbol. For me the following test program compiles: #include <stdint.h> uint8_t test(uint8_t* ptr, uint8_t val) { return __sync_fetch_and_add_1(ptr, val); } int main(void) { uint8_t n; return test(&n, 1); } Does that compile for you? Which version of GCC do we end up using on Windows? The reported symbol (___sync_fetch_and_add_1) has three leading underscores, that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates a reference to that symbol? 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: Aargh! The Windows build has broken – again. I can’t build GHC on my laptop any more. A clean ‘sh validate’ finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

2 1

performance monitoring idea
by Richard Eisenberg 16 Jul '14

16 Jul '14

Hi all, I'm deep into working on #9233 right now, which may stem from various inefficiencies due to roles. I'm making good progress, and I feel badly about introducing these problems. When I was coding this originally, I was thinking "Premature optimization is the root of all evil" and didn't pay too much attention to performance, thinking that a perf test would show me up if I erred. I was wrong. This all got me thinking: could we track some cumulative timing numbers for running the whole testsuite? As a first draft, it could just be the sum of the MUT statistic from +RTS -t. As part of our growing CI support (thanks, Joachim and others!!), we could track this number over time. When a commit slows GHC down, we would hopefully see it reflected here and then try to catch these bugs earlier, in an effort to defy Lennart's expectations of GHC slowing down every release. (Sorry, can't find reference to quote at the moment.) This idea seems easy enough to implement. It may not be terribly reliable, but it might just be reliable enough to help catch these problems before releases and to help to discover where they came from. What do we think? Richard

1 0