- ghc-devs - Haskell.org

Help! Windows build broken in teestsuite
by Simon Peyton Jones 07 Jun '16

07 Jun '16

Aargh! The Windows build is broken again. This time it’s the testsuite. It seems to be trying to run the test in a temp directory, and failing to find the directory. Thomie, could this be something to do with your work on the testsuite? Please fix! Or tell me what to revert. It leaves me stuck. Thanks Simon /cygdrive/c/code/HEAD/testsuite/tests/indexed-types/should_fail$ make TEST=T9662 PYTHON="python" "python" ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=0 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e cleanup=True --rootdir=. --configfile=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/cygdrive/c/code/HEAD/testsuite"' --config 'compiler="/cygdrive/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/cygdrive/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/cygdrive/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/cygdrive/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' \ --only=T9662 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at 06/07/16 07:45:13 GMT Summer Time ====> Scanning ./all.T =====> T9662(normal) 1 of 1 [0, 0, 0] cd c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw\1\2\3\.\T9662 && "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T9662.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history > T9662.comp.stderr 2>&1 sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory

1 0

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"
by Herbert Valerio Riedel 06 Jun '16

06 Jun '16

Hello! In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>) subtly conflicts with definitions of (<>) in pretty printing APIs, for which the left-associative variant is sometimes desirable. This subtle overloading of (<>) is error-prone, as one has to remember which version of (<>) is currently in scope in order to be able to reason about non-trivial expressions involving this operator. This proposal is an attempt to resolve this unfortunate and confusing situation by completing the `Semigroup`/`Monoid` vocabulary with a standard left-associative alias. Please see https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp for more details. Discussion period: 4 weeks

2 1

x86-64 unknown-linux
by Richard Eisenberg 06 Jun '16

06 Jun '16

Hi devs, I would like to download GHC 8 binaries for Arch Linux on an x86-64 architecture. I assume I'm looking for an unknown-linux build, and it looks like what I want is a Tier 1 platform, according to https://ghc.haskell.org/trac/ghc/wiki/Platforms Yet I don't see this release in https://downloads.haskell.org/~ghc/8.0.1/ Can you help? Thanks! Richard

2 2

Why does the LLVM invoke command-line tools instead of using the library?
by Nicola Gigante 05 Jun '16

05 Jun '16

Hi all, while looking at the GHC 8 Trac page I encountered the page about the plans for the improved LLVM backend: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend <https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend> I know nearly nothing about the internals of the GHC backend so I may be asking something trivial, but from reading that page I understand that GHC currently calls LLVM command line tools to optimize and compile the IR, is it right? LLVM is a C++ library, but it also exports a portable and stable C API which I think is already covered by the llvm-general package. So as someone who worked on LLVM in the past, and appreciated its library-based integration-friendly design I’m wondering why is GHC using the command line tools instead of linking to the library? Best Regards, Nicola

2 1

Break Base Faster
by Ericson, John 02 Jun '16

02 Jun '16

I'm excited for the various proposals to clean up base's warts, but the time-frames over which to distribute the breaking changes are just so long---approaching a decade IIUC for Monad-Fail for example. First off, If anybody has some links to where/why the long transitions were proposed, I'd love to read them as I am not sure of the exact motivation. If, in fact, we could just break everything all at once without pissing people off, then the rest of my email can be discarded :). As I see it, the underlying issue here is that we are assuming each GHC version will only work with one version of base. Well, as it stands, none of the proposed *breaking* changes interact much with the language itself, so the relationship between base and GHC is less constrained than it seems. I went on #ghc and learned that multiple bases was tried in the past for Haskell98 compatability and exceptions in 6.10, and the experience was unpleasant. But I hope that Cabal support for multiple versions of a package in a single build plan ( http://www.well-typed.com/blog/2015/07/cabal-setup-deps/) Stackage package sets, and split base can improve the experience this time around. Cabal improvements perhaps open the door to linking packages that use different base versions together, with blanket instances from e.g. (new.Monad, new.MonadFail) => old.Monad to ease the pain. With package-qualified-imports, I hope we can have legacy base import from base, but otherwise we can make them both rely on other packages (especially with split-base), from which base will just re-export definitions. In the event that linking both bases is impossible, or the blanket instances are insufficient for making the same library work with other libraries requiring either base. Stackage will allow for curating separate package sets for each base version. I imagine the prospect of splitting the Haskell ecosystem with multiple bases sounds daunting to some, but package sets like Stackage provides provide enough cohesion *within* the ecosystem centered around each base that I'd wager we'd still be in better shape than how things were circa 6.10. Finally, split base I hope will generally make experimentation easier by allowing packages to specify more exactly what they need, and lower the barrier of entry for new bases. As mentioned above, it allow for legacy base to more more naturally contain blanket instances of normal base's classes by avoiding package-qualified imports. For the first release with split base, I'd follow Rust's example where base is a "facade" and the packages that back it are initially unstable like ghc-prim. According to https://ghc.haskell.org/trac/ghc/wiki/SplitBase#Non-Obviousinterdependencies, the completion of MonadFail is in fact a big prerequisite to an acyclic split base. If my previous statements are correct on the benefits of split base, this puts us in an pleasant situation where MonadFail can speed up split base, and split base can speed up Monad fail. As a final thought, I think that multiple bases is far superior than taking the "-compat" route a la transformers-compat: IMO the need to change upstream code to use "-compat" severely negates the benefits. John

2 1

Deriving Generic1
by Simon Peyton Jones 01 Jun '16

01 Jun '16

Ryan If you compile newtype Compose f g a = Compose (f (g a)) deriving( Generic1 ) and do –show-iface on the resulting hi file, you’ll see $fGeneric1Compose :: forall (f :: * -> *) k (g :: k -> *). Functor f => Generic1 (Compose f g) I was expecting to see $fGeneric1Compose :: forall (f :: k1 -> *) k (g :: k -> k1). (..something..) => Generic1 (Compose f g) Otherwise the Generic1 instance only works if its first argument has kind (* -> *). Is that the intention? Maybe so… Simon

2 1

Core of a whole package
by Alberto Sadde O. 01 Jun '16

01 Jun '16

Hi, I am trying to get the Core of a whole package. I have been using the GHC API to get the Core of each file in a package but I have a problems with non-exposed modules of the package. I might not been setting up all the flags correctly but at this point I am completely lost!! I posted a question on S.O. <http://stackoverflow.com/questions/37410615/ghc-api-compile-whole-package-t…> The code I am using is in the above link. Any help/comments/tips would be greatly appreciated! Many thanks, Alberto

2 5

Re: Strictness/laziness warnings
by David Feuer 30 May '16

30 May '16

Mostly I'm looking for a rough estimate. Some false positives and false negatives are tolerable. If I have something like f :: Int -> Maybe String -> String f _ Nothing = "Hi there!" f n (Just b) = if n > 0 then show b else "whatever" then I'd likely be interested in a warning about the fact that the first case is not strict in the Int and the second is. I'd also likely be interested in a warning about the first case because I'm taking a small primitive value (Int) and doing so lazily. On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje(a)gmail.com> wrote: > On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett(a)gmail.com> wrote: >> How would you detect the argument only being forced some of the time? Sounds >> like a lot of long-term cross-module book-keeping. > > Sounds to me like what the strictness analyzer is already doing, ne? I > missed the beginning of the thread, so might be off base. If it's more > about noticing when the use sites of a given function have some > pattern not captured by the strictness determined from the function's > definition, then it seems like we shouldn't need /cross/-module > bookkeeping: we should be able to just tabulate how each use site's > strictness does/doesn't match the interface's spec. > > -- > Live well, > ~wren

2 1

GHC HEAD (built with itself) blows allocation stats :-(
by Gabor Greif 30 May '16

30 May '16

Hi devs, I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why, but this is with a stage-0 compiler that is also GHC HEAD. (I doubt that that is the reason, though.) I see on a linux x64 system (RHEL6) : Unexpected stat failures: /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370 T10370 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547 T10547 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969 T1969 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064 T3064 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294 T3294 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801 T4801 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030 T5030 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD T5321FD [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321Fun T5321Fun [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631 T5631 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642 T5642 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837 T5837 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048 T6048 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783 T783 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020 T9020 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233 T9233 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675 T9675 [stat not good enough] (optasm) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a T9872a [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b T9872b [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c T9872c [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d T9872d [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961 T9961 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001 parsing001 [stat not good enough] (normal) /tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029 T4029 [stat not good enough] (ghci) Some of the tests look like this: cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a && "ghc-head-x86_64/inplace/test spaces/ghc-stage2" -c T9872a.hs -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history +RTS -V0 -tT9872a.comp.stats --machine-readable -RTS > T9872a.comp.stderr 2>&1 bytes allocated value is too high: Expected T9872a(normal) bytes allocated: 3352882080 +/-5% Lower bound T9872a(normal) bytes allocated: 3185237976 Upper bound T9872a(normal) bytes allocated: 3520526184 Actual T9872a(normal) bytes allocated: 13260131240 Deviation T9872a(normal) bytes allocated: 295.5 % *** unexpected stat test failure for T9872a(normal) Around 300% looks really bad. Can anybody reproduce this? For reference, this is the test command I run: $ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001 T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631 T5321FD T5030 T4801 T6048 T9675 T9233 T9020" The testsuite works nicely otherwise. Cheers and thanks, Gabor

3 5

comment lines in Cmm outputs
by Ömer Sinan Ağacan 29 May '16

29 May '16

I'm reading a lot of Cmm these days and comments added by Cmm dump (which are apparently added after 8.0.1) are so annoying becuase they're not saying anything useful (what's the point of adding "// CmmCall" to a "call" line or "// CmmCondBranch" to a "if" line?) but making a lot of noise. Why were those added? Can we remove them?

2 4