- ghc-devs - Haskell.org

The build is broken on {32,64}-bit Windows
by Páli Gábor János 15 Sep '14

15 Sep '14

Hello there, For your information, the build has been failing for a few days now on both my Windows builders [1][2], basically in the same way. [...] librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Could somebody do something with this, or does anybody have hints on how to fix this? Looks like the culprit is the haskeline library. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html

2 1

It's that time again (for the HCAR)
by Austin Seipp 15 Sep '14

15 Sep '14

Hi *, It is that time again where once every 6 months, we write our entry for the Haskell Communities and Activities Report (HCAR), summarizing what exactly we're all doing. I say 'we' write this of course because I need everyone to write some stuff on what they're doing. :) I'll editorialize it before sending it in, but please feel free to add things. I've drafted a very basic page, based on the last one: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 I sort of selectively cherry-picked some things from the prior 7.10 updates. Again, please feel free to add things as you see fit. I eagerly await your edits! Let's try to get this one done on time. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Preliminary proposal: Monoidal categories in base and proc notation support
by Sophie Taylor 15 Sep '14

15 Sep '14

Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor

3 2

Re: The list fusion lab
by David Feuer 14 Sep '14

14 Sep '14

Joachim Breitner wrote: > 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 Many thanks to you both! This sounds like an excellent idea. I do hope someone figures out a way around the criterion dependency shortly. Alternatively/longer term, I would love to see criterion refactored a bit—separating benchmarking and analysis into separate packages would presumably help with its dependency problems, and having the benchmarking side work with GHC HEAD reliably would be a Good Thing.

3 3

Re: FoldrW/buildW issues
by David Feuer 14 Sep '14

14 Sep '14

Joachim Breitner wrote: > Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: > > On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> > > wrote: > > > Interesting. I assumed that some wrap.unwrap=id law would hold, or > > at > > > least some moral approximation (e.g. disregarding bottoms in an > > > acceptable manner). But if the wrappers have to do arbitrary stuff > > that > > > can arbitrarily interact with how the producer calls them, this > > becomes > > > a bit less appealing. > > > > No, nothing pleasant like that, I'm afraid. isoSimple is like that of > > course, but once it gets to foldl, the fusion rule is handing the > > builder a wrap/unwrap pair that isn't even close to that. > > and parametricity doesn't help here? Note that due to the forall in the > type of buildW, you can probably reason about what kind of values buildW > can produce, as it can only use whatever the consumer handed to it. > Maybe there is an invariant for that type, and the worker/wrapper pair > is the identity for values that fulfill that invariant. > That seems reasonable, and I suspect without any proof that Takano Akio's wrapper for foldl and Dan Doel's wrapper for reverse probably satisfy it. Scans seem to be more of a challenge. It appears to me that Dan's scanl wrapper probably does *not* satisfy that requirement, and I don't know enough to have much chance of finding one that does. David

3 3

Re: FoldrW/buildW issues
by David Feuer 13 Sep '14

13 Sep '14

On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> wrote: > Interesting. I assumed that some wrap.unwrap=id law would hold, or at > least some moral approximation (e.g. disregarding bottoms in an > acceptable manner). But if the wrappers have to do arbitrary stuff that > can arbitrarily interact with how the producer calls them, this becomes > a bit less appealing. No, nothing pleasant like that, I'm afraid. isoSimple is like that of course, but once it gets to foldl, the fusion rule is handing the builder a wrap/unwrap pair that isn't even close to that. > > 2. Somewhat related to the above, this framework has a huge amount of > > "wiggle room". There is very little to guide the choice of Wrap type. > > I guess that would be resolved by time and experience, if we’d employ > that scheme. But maybe we don’t. The only way I would imagine would be if it turned out there were a few types that could be composed somehow. But when I, experimentally, applied Dan Doel's scanl wrapper type combined with Simple to (!!), I just got wrong answers. > > Do you have any ideas? > > Directly related to foldrW, no. > > About list fusion and foldl in general, some half-baked. > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. How does that work exactly? Where do you stick the oneShot/why is it valid? > Another idea, probably with the same effect: What happens if we extend > build :: (forall b. (a -> b -> b) -> b -> b) -> [a] > to > buildI :: (forall b. (a -> b -> b) -> b -> (b -> b) -> b) -> [a] > where the extra argument is the identity, but magically „improves values > of type b“. So with > > enum = buildI $ \c n imp -> go 0 > where go i = imp $ case i of 100 -> n ; _ -> i `c` go (i+1) > > and > > foldl f a0 = foldrI (\x k a -> k (f x a)) id (\k a -> k a) a0 > > we might get good code (but this is half-baked and written as I go). It sounds a lot like the foldrW/buildW thing again, but maybe you can do better with it. > Shouldn’t this be on ghc-dev where others can join an, and people will > find it in the archives later? I prefer to reserve private mail to, > well, private matters :-) If you like. David

2 1

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