November 2015 - ghc-devs

Wildcard refactor
by Simon Peyton Jones 18 Nov '15

18 Nov '15

Alan I'm really close on wip/spj-wildcard-refactor, that I really want to get into HEAD asap. Could you possibly checkout wip/spj-wildcard-refactor, and validate? I get two failures I don't understand: ghc-api/annotations listcomps [bad stdout] (normal) ghc-api/landmines landmines [bad stderr] (normal) The output is not wildly different but I just don't know how to interpret it, so I don't even know what the problem is exactly. NB: you''ll need to do a 'git submodule update' because the haddock submodule changes. Thank you! Simon

2 1

Re: Window build broken
by Ryan Scott 18 Nov '15

18 Nov '15

Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeader (COFF_header *hdr, pathchar *fileName) { if (hdr->Machine != 0x8664) { errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName); return 0; } ... } Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10437 [2] https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rt…

3 2

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
by Richard Eisenberg 17 Nov '15

17 Nov '15

On Nov 4, 2015, at 11:12 AM, Peter Trommler <Peter.Trommler(a)th-nuernberg.de> wrote: > It looks like a bug to me. I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. I tend to agree -- I was surprised to see this, but I'm almost-totally clueless about these things. Thanks for the info, Richard PS: There's been much muttering about call stacks and DWARF. I haven't a clue what DWARF is, but I always assumed that this nice feature would not be available on Macs. What I realized today is that this assumption likely stems from the fact that ELF is not for Mac. ELFs and DWARFs tend to be found near one another in other settings, but perhaps this fact doesn't carry over to computer architectures. :) > > Cheers, > > Peter > >> On 04.11.2015, at 16:46, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >> >> I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this: >> >>> checking for readelf... no >>> configure: error: cannot find readelf in your PATH >> >> A (very) quick search has turned up no help. I'm worried that my problem is that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track of all the animals... and now mountains.) I *really* don't want to upgrade, as I tried 10.9 once and it brought my system to its knees... had to reformat to downgrade back to 10.8. >> >> Help? >> >> Thanks! >> Richard >> > > > > -- > Prof. Dr. Peter Trommler email: peter.trommler(a)th-nuernberg.de > Technische Hochschule Nuernberg phone: +49-911-58 80-16 63 > Faculty of Computer Science fax: +49-911-58 80-56 66 > Postfach 31 03 20, 90121 Nuernberg office: Hohfederstrasse 40, 90489 Nuernberg > >

3 2

too many lines too long
by Richard Eisenberg 17 Nov '15

17 Nov '15

Hi devs, We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard

17 23

Further custom type error questions
by Ben Gamari 17 Nov '15

17 Nov '15

While preparing some additional documentation for Iavor's custom type errors work (which has been merged; thanks Iavor!) I noticed that Dominique Devriese has raised some additional questions on the proposal [1]. In particular, Dominique suggests that perhaps TypeError should simply be of kind `ErrorMessage -> Constraint`. My understanding of the proposal is that the intention is that `TypeError`s should be usable on the RHS of type functions, like `error` on the term level. However, is this strictly necessary? Is there any place where you couldn't just as easily express the `TypeError` as a constraint? If not, it seems like this may be substantially simpler approach and totally side-steps the detection of `TypeError` in inappropriate places on the RHS. Regardless, it seems like this (and the other questions) is worth addressing in the proposal. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#Somedesignq…:

5 4

process librarry
by Simon Peyton Jones 16 Nov '15

16 Nov '15

Michael My Windows build (sh validate in a clean tree) is still falling over as follows, on Windows. Would it be possible to fix the process library to stop this happening? Thanks Simon libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor `CGid'

2 1

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang
by George Colpitts 16 Nov '15

16 Nov '15

I did get compiling from source to work on the Mac. Unfortunately I'm not sure what the problem was. I now see a new problem, not sure if it is a ghc problem or a library problem: cabal install HsOpenSSL ... Building HsOpenSSL-0.11.1.1... Preprocessing library HsOpenSSL-0.11.1.1... In file included from BN.hsc:45: cbits/HsOpenSSL.h:3:10: fatal error: 'openssl/asn1.h' file not found #include <openssl/asn1.h> ^ 1 error generated. compiling dist/build/OpenSSL/BN_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/OpenSSL/BN_hsc_make.c -o dist/build/OpenSSL/BN_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -D PTHREAD -DCALLCONV=ccall -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/Users/gcolpitts/Library/Haskell/ghc-7.10.2.20151105-x86_64/lib/network-2.6.2.1/include -I/usr/local/lib/ghc-7.10.2.20151105/unix_KZL8h98IqDM57kQSPo1mKx/include -I/usr/local/lib/ghc-7.10.2.20151105/time_FTheb6LSxyX1UABIbBXRfn/include -I/usr/local/lib/ghc-7.10.2.20151105/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/usr/local/lib/ghc-7.10.2.20151105/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.2.20151105/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.2.20151105/include -I/usr/local/lib/ghc-7.10.2.20151105/include/ cabal: Error: some packages failed to install: HsOpenSSL-0.11.1.1 failed during the building phase. The exception was: ExitFailure 1 /usr/bin/gcc --version /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix On Mon, Nov 9, 2015 at 10:49 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > redid with just make rather than make -j5. I get > > > ... > chmod +x libraries/integer-gmp2/gmp/ln > # Their cmd invocation only works on msys. On cygwin it starts > # a cmd interactive shell. The replacement works in both environments. > mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh > cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; > export SHELLOPTS; \ > PATH=`pwd`:$PATH; \ > export PATH; \ > cd gmpbuild && \ > CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ > --enable-shared=no \ > --host=x86_64-apple-darwin --build=x86_64-apple-darwin > /bin/sh: SHELLOPTS: readonly variable > checking build system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking host system type... /bin/sh: SHELLOPTS: readonly variable > /bin/sh: SHELLOPTS: readonly variable > x86_64-apple-darwin > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /bin/sh: SHELLOPTS: readonly variable > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking ABI=64 > checking whether clang is gcc... yes > checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 > char spilling > checking ABI=32 > checking whether clang is gcc... yes > *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... > no, gnupro alpha ev6 char spilling* > *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, > gnupro alpha ev6 char spilling* > *configure: error: could not find a working compiler, see config.log for > details* > *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* > *make: *** [all] Error 2* > > > On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > >> George Colpitts <george.colpitts(a)gmail.com> writes: >> >> > I get >> > >> > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 >> > make[1]: *** Waiting for unfinished jobs.... >> >> It looks like the build failed somewhere before this point. Could you >> provide a more complete log? >> >> Cheers, >> >> - Ben >> >> >> >

4 15

mac build for 7.10.3 RC
by Carter Schonwald 15 Nov '15

15 Nov '15

here yah go! this should fix issues with my earlier build http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.… $ shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 6bf9c93e217a148e97884db447cbeb2d9370facecc61d81cf7e47cf1f66ad664046f79e0813117342dcd811fd0e290fa0247a34cbd26c7c577f7159f51f4bbbe ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2 for those who want the check sum

2 1

build system issue: some changes in libraries doesn't trigger required rebuilds
by Ömer Sinan Ağacan 15 Nov '15

15 Nov '15

Hi all, I'm having this annoying issue all the time: Whenever a `git pull origin master` updates a library(one of the submodules, like `Binary`) a `make` doesn't trigger required rebuilds(e.g. it doesn't rebuild libraries and tries to rebuild GHC code). I don't know how to force build libraries, so most of the time I end up doing `make distclean` and wasting 30 minutes. I was wondering if there's a way to force rebuilding libraries? Or can we fix the build system somehow?

2 1

Can't build current HEAD
by Jan Stolarek 14 Nov '15

14 Nov '15

I am unable to build current HEAD. I'm getting a build error in Outputable module: compiler/utils/Outputable.hs:1046:28: Not in scope: type constructor or class ‘CallStack’ compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’ The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which added this: #if __GLASGOW_HASKELL__ >= 710 pprSTrace :: (?location :: CallStack) => SDoc -> a -> a pprSTrace = pprTrace (showCallStack ?location) #else pprSTrace :: SDoc -> a -> a pprSTrace = pprTrace "no callstack info" #endif The most interesting thing is that if I change the definition of pprSTrace in the first branch of #if to be identical to the definition in the second branch, then I get warnings that GHC.Stack and GHC.Exception imports are redundant. Any ideas what might be going on here? I'm compiling using GHC 7.10.1. This happens in a clean build tree. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2