September 2014 - ghc-devs

HEAD fails to bootstrap with HEAD?
by Karel Gardas 12 Sep '14

12 Sep '14

Hello, I've noticed that probably after cabal/ghc-pkg changes done recently HEAD fails to build with HEAD in following way: [80 of 80] Compiling Main ( utils/ghc-cabal/Main.hs, bootstrapping/Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal "inplace/bin/mkdirhier" compiler/stage1/build//. "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. "inplace/bin/ghc-cabal" configure libraries/Cabal/Cabal dist-boot "" --with-ghc="/opt/ghc-7.9.20140906-amd64/bin/ghc" --with-ghc-pkg="/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg" --package-db=/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --with-hscolour="/export/home/karel/.cabal/bin/HsColour" --configure-option=CFLAGS=" -m64 -fno-stack-protector " --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 " --gcc-options=" -m64 -fno-stack-protector -m64 " --configure-option=--with-gmp-includes="/usr/include/gmp" --configure-option=--with-gmp-libraries="/usr/lib/" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.1" --constraint "binary == 0.7.1.0" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.1" --constraint "transformers == 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/xpg4/bin/ar" --with-alex="/export/home/karel/.cabal/bin/alex" --with-happy="/export/home/karel/.cabal/bin/happy" Configuring Cabal-1.21.1.0... ghc-cabal: '/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. gmake[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 gmake: *** [all] Error 2 I've been able to solve this by: $ rm libraries/bootstrapping.conf $ /opt/ghc-7.9.20140906-amd64/bin/ghc-pkg init libraries/bootstrapping.conf however it's kind of impractical to do that on buildbot (solaris/amd64). Is it possible to fix that somehow? Thanks! Karel

2 1

win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux
by Mikolaj Konarski 12 Sep '14

12 Sep '14

Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors): http://www.haskell.org/haskellwiki/GHC_under_Wine https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 Examples of both kinds of binaries, for a project with gtk2hs and TH dependency: https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0 Please share your success reports here or on the wiki and let's exchange ideas, file concrete tickets and propose patches to make the two processes more accessible. Some tickets are mentioned in the wikis or can be traced from there, but there may be others I'm not aware of, so let's link them where appropriate. Hope this helps somebody, Mikolaj

1 1

AMP performance effect
by Joachim Breitner 12 Sep '14

12 Sep '14

Hi, nothing overly exciting, but since I am running this ghcspeed thing, I guess I should inform you about changes, just to get some practice doing that :-) Due to various build failures, the AMP landing patch was not measured in isolation, so these numbers reflect the effect of these patches: $ git log fdfe6..1e400 --oneline 1e40037 Update nofib submodule to fix errors in main suite. 841924c build.mk.sample: Stage1 needn't be built with -fllvm 68ecc57 base: replace ver 4.7.1.0 references by 4.8.0.0 c6f502b Bump `base` version to 4.8.0.0 for real 27a642c Revert "base: Bump version to 4.8.0.0" 0829f4c base: Bump version to 4.8.0.0 d94de87 Make Applicative a superclass of Monad If you want to have a look yourself, see http://ghcspeed-nomeata.rhcloud.com/changes/?rev=1e40037604&exe=2&env=1 Notable points: * nofib running times are unchanged on average. * binary sizes are consistently reduced by a small amount (-0.7%) * one nofib benchmarks show significant increases in allocation: - cryptalgorithm2 +17,5% Unfortunately, cryptalgorithm’s runtime is below the cut-off, so I cannot tell if that has changed significantly. - all other nofib benchmarks have unchanged allocation numbers * some testsuite benchmarks as well: - T3064 +28% - T5631 + 7% - T9020 +18% - haddock-* +3% - many with no change at all, some with noise up to +2,7% I don’t think this requires action, but if someone feels inclined to find out what happened to cryptoalgorithm2 (which uses StateT), feel free to give it a shot! 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

3 4

The list fusion lab
by Joachim Breitner 11 Sep '14

11 Sep '14

Hi, especially David and Dan, I wanted to announce this only when I had time to polish more corners, but since you are busy hacking on list fusion, experimenting with foldrW etc., maybe it’s better to release early (and you might enjoy polishing the corners yourself). Together with John Wiegly at ICFP, I started to create a list performance laboratory. You can find it at: https://github.com/nomeata/list-fusion-lab The idea is simple: Have a number of modules (in ListImpls/) that provide the same list functions (see ListImpls/exports). Then there is a test suite (Benchmarks.hs) and a driver (driver.hs). The latter takes, as arguments, a number of ghc binaries and a number of modules from ListImpls, compiles a small helper (ListTestsTemplate.hs) with all combinations (using CPP to select the right module), runs the benchmarks and aggregates the results. Note that the tests are not run in the same process as the runner, which reduces the number of libraries that the tested compiler needs to have installed. It is half finished in a few ways: * The reporting is unfinished. We used criterion’s default, but it is not quite what we want to see. * It still requires the tested compiler to have criterion installed, which is tricky for GHC-HEAD. I’d like to have two modules providing a function "(Int -> ()) -> IO Double", one with criterion and one with some ad-hoc measurement, and a way for the driver to choose. This way you can get rough measurements without criterion. * I’d like to also measure allocations. Again, that’d be nicer with a way of running the benchmarks without criterion. * There are clearly not enough benchmarks. The plan for this is that when evaluating a different implementation of a list function, or possibly a completely different fusion implementation (foldrW, stream fusion), we can simply add it here and have something reliable to base our decisions on, instead of waiting for one of the experienced wizards to come along and cast a verdict. Enjoy, and send pull requests! 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

1 0

deleting branches
by Simon Peyton Jones 10 Sep '14

10 Sep '14

I accidentally created a branch (in the main repo) called origin/origin/wip/new-flatten-skolems-Aug14 I was trying to make a local branch to track the existing origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a local branch called origin/wip/new-flatten-skolems-Aug14, which I then pushed, creating the one above. It's quite confusing to me that branches (listed with git branch -av) have names like wip/rae and remotes/origin/wip/rae I suspect that the "remotes/origin" part isn't really part of the name of the branch at all, even though it is not syntactically distinguished. Anyway, I'd like to delete that branch from the main repo on the server, but I don't know how to do so. I tried git branch -D origin/origin/wip/new-flatten-skolems-Aug14 error: branch 'origin/origin/wip/new-flatten-skolems-Aug14' not found. My model of branch naming is not working well. Can anyone advise? Simon

3 2

No context in error messages
by Corentin Dupont 09 Sep '14

09 Sep '14

Hi everybody, I am working with Hint, after some discussion with Daniel Gorin, I decided to post here, I hope it's the right place. My problem with Hint is that I cannot get context in error messages while interpreting a string. If you run the attached file example.hs, you get: GhcError {errMsg = "No instance for (GHC.Num.Num GHC.Base.String)\n arising from a use of `GHC.Num.+'\nPossible fix:\n add an instance declaration for (GHC.Num.Num GHC.Base.String)"} There is no context (line number, code snippets...), plus the error message uses fully qualified names, which is not very readable. It's very hard to figure out where the problem is when interpreting a long string. But the same error in a file that is loaded with Hint gives the correct message (uncomment the putStrLn in SomeModule.hs to get it): GhcError {errMsg = "<no location info>:\n [1 of 1] Compiling SomeModule ( SomeModule.hs, interpreted )"},GhcError {errMsg = "SomeModule.hs:5:22:\n No instance for (Num String) arising from a use of `+'\n Possible fix: add an instance declaration for (Num String)\n In the second argument of `($)', namely `\"bar\" + 1'\n In a stmt of a 'do' block: putStrLn $ \"bar\" + 1\n In the expression:\n do { putStrLn \"bar\";\n putStrLn $ \"bar\" + 1 }"} This error is much better: it gives line number plus some code snippets ("In the second argument of..."). There might be a flag that is not correctly set in GHC? After a quick look I'm thinking of GHC.DynFlags (I'm no expert). Now it is configured with: configureDynFlags :: GHC.DynFlags -> GHC.DynFlags configureDynFlags dflags = dflags{GHC.ghcMode = GHC.CompManager, GHC.hscTarget = GHC.HscInterpreted, GHC.ghcLink = GHC.LinkInMemory, GHC.verbosity = 0} Thanks, Corentin

1 1

Trying to fix an efficiency issue noted in a TODO in SAT.hs
by David Feuer 09 Sep '14

09 Sep '14

compiler/simplCore/SAT.hs has a TODO comment about the fact that it does a fair bit of appending onto the ends of lists, and that should be done differently. I made an attempt to fix it. The complexity of the recursion, however, leaves me uncertain as to whether I really did or not. I've attached a diff and I hope someone will be able to take a look at it. The only use of Sequence.fromList is source line 172, and the only significant use of Foldable.toList (aside from pretty-printing) is on source line 402. Note that the use of Sequence may be temporary—I want to get the right code structure down before choosing the best data structure. Thanks, David Feuer

3 2

What is testsuite/tests/rename/should_fail/rnfail018.hs supposed to test?
by David Feuer 09 Sep '14

09 Sep '14

When I compile this with 7.8.3, it gives an error message saying that type variables a and m are not in scope. If I add them to the forall, it tells me I need FlexibleContexts. If I add that, then it gives me an error about an ambiguous type variable. Clearly, something crashed ghc-4.04proto, but there's no indication of what that was. If this test is still at all relevant, it probably needs to be updated to target something more narrowly. The program: {-# LANGUAGE MultiParamTypeClasses, ExplicitForAll #-} module ShouldFail where -- !!! For-all with parens -- This one crashed ghc-4.04proto; the parens after the for-all fooled it class Monad m => StateMonad s m where getState :: m s setState0 :: forall b. (StateMonad (a,b) m => m a) setState0 = getState >>= \ (l,_r) -> return l David Feuer

2 1

NOTE: Minor downtime for Trac/ghc/git.haskell.org today
by Austin Seipp 07 Sep '14

07 Sep '14

Hi *, In about 1 hour from now (12:30pm CDT), Trac, git.haskell.org, and ghc.haskell.org may be temporarily unavailable for 5 to 10 minutes or so. We're moving the server to a new dedicated host as a result of all the availability problems the past few days. The downtime will mostly accommodate the time needed for DNS switchover to a new IP. As a bonus, the new server should keep us going for a very long time, and has a nice amount of bandwidth dedicated to it, as well as IPv6. Please DO NOT push things to the git repositories; it will be blocked. Don't edit Trac; we'll be revoking ACL write permissions most likely for a short window. Note that I have set the DNS TTLs for Haskell.org to a very low value to facilitate the IP change. If you have connectivity problems after that, let me know. I'll email again when the expected downtime is starting/completed. You can also check http://status.haskell.org for more. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 2

Re: Trying to fix an efficiency issue noted in a TODO in SAT.lhs
by David Feuer 07 Sep '14

07 Sep '14

Joachim Breitner wrote: > Did you profile first, and did it show up there? You know, premature > optimization... so it might be that your fix is a nice improvement and > useful exercise (and very welcome as such), but without much real-world > effect. You're right, of course. I read the comment and figured it made sense, but it may not really make much. In particular, the lists involved will usually be short, so O(n^2) may not actually be bad. It would probably be more valuable for me to start by trying to make it easier to follow what's going on (and I've submitted one patch to do so for one of the functions) and think about efficiency later or not at all. > BTW, code review is easier on Phabricator. Maybe you want to get started > using that? See https://ghc.haskell.org/trac/ghc/wiki/Phabricator for > instructions. I'll take a look. There are a million tools to learn.

1 0