- Glasgow-haskell-users

Does ghc 7.6.1 support gold ld?
by Magicloud Magiclouds 10 Oct '12

10 Oct '12

Hi, Since gold ld (GNU gold (GNU Binutils for Debian 2.22) 1.11) somehow better than ld, so I am using it in my debian box. Now I want to compile ghc 7.6.1 with it. And I have modified the configure script to skip checking --hash-size, --reduce-memory-overheads and if is gnu ld (all fixed to NO). And using normal build ghc 7.6.1. I got following errors. What should I do? 2012/10/10 Wed 13:32:01 magicloud@ctu1-tes-02 ~/src/ghc-7.6.1 4617 $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] libraries/base/dist-install/build/GHC/Exception.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Err.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Char.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Enum.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Real.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/Text/ParserCombinators/ReadP.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/Text/Read/Lex.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/ST.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Arr.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/Data/Bits.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Float.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/Text/ParserCombinators/ReadPrec.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Read.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/Numeric.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/Ptr.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) HC [stage 1] libraries/base/dist-install/build/GHC/STRef.o ghc-stage1: fd:5: hGetContents: invalid argument (invalid byte sequence) make[1]: *** [libraries/base/dist-install/build/GHC/STRef.o] Error 2 make[1]: *** Deleting file `libraries/base/dist-install/build/GHC/STRef.o' make: *** [all] Error 2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

1 1

what are good starter tasks for getting involved with ghc dev?
by Carter Tazio Schonwald 10 Oct '12

10 Oct '12

Hey All, I'm interested in getting involved in (/ helping out ) with dev work on GHC, what are good ways to get started on tackling smaller bits in the near term? (better to do simple things before more ambitious things after all!) should i just go through the issue tracker for tasks or bugs that are un assigned that I think i can do, and see if I can do them? thanks!-Carter

1 0

copyArray# bug
by Roman Leshchinskiy 09 Oct '12

09 Oct '12

I've been chasing a segfault in the dev version of vector and I think I finally traced it to a bug in the implementation of copyArray# and copyMutableArray#. More specifically, I think emitSetCards in StgCmmPrim.hs (and CgPrimOp.hs) will sometimes fail to mark the last card as dirty because in the current implementation, the number of cards to mark is computed solely from the number of copied elements while it really depends on which cards the first and the last elements belong to. That is, the number of elements to copy might be less than the number of elements per card but the copied range might still span two cards. The attached patch fixes this (and the segfault in vector) and also makes copyArray# return immediately if the number of elements to copy is 0. Could someone who is familiar with the code please review it and tell me if it looks sensible. If it does, I'll make the same modification to CgPrimOp.hs (which has exactly the same code) and commit. Unfortunately, I have no idea how to write a testcase for this since the bug is only triggered in very specific circumstances. It seems that all released versions of GHC that implement copyArray#/copyMutableArray# have this problem. At least, vector's testsuite now segfaults with all of them in roughly the same place after recent modifications I've made (which involve calling copyArray# a lot). If I'm right then I would suggest not to use copyArray# and copyMutableArray# for GHC < 7.8. Roman

4 8

Recompiling a module fails
by Jeroen Weijers 09 Oct '12

09 Oct '12

I'm currently having a problem with compiling modules. I have two files Data.hs and Class.hs (Class depends on Data). When I compile Class.hs (ghc --make Class.hs) the ghc does what it should do. When I now make a change to Class.hs (add a newline to the end of the file for example) and try to run ghc --make Class.hs again the ghc gets stuck on recompiling Class.hs. I think this is a bug in the GHC, can anybody confirm this? (it only occurs in GHC-7.6.1 both x86 and i386 versions, GHC-7.4 doesn't have this problem, I only tried it on OS X). Or did I miss something else? It doesn't happen when the Exp data type in Data.hs only has one constructor. Contents of the two module involved: Class.hs >{-# LANGUAGE GADTs, TypeFamilies #-} >module Class where > >import Data > >data Q a where > Q :: QA a => Exp (F a) -> Q a > >class QA a where > type F a Data.hs >{-# LANGUAGE GADTs #-} >module Data where > >data Exp a where > LamE :: (Exp a -> Exp b) -> Exp (Exp a -> Exp b) > VarE :: Integer -> Exp a Cheers, Jeroen

1 0

Installing binary tarball fails on Linux
by Johan Tibell 09 Oct '12

09 Oct '12

Hi, I tried to install the GHC 7.4.1 32-bit binary tarball today and ran into the error below. Are 32-bit GHC's not supported on 64-bit Linuxes? The error: Installing library in /usr/local/lib/ghc-7.4.1/ghc-prim-0.2.0.0 ghc-cabal: Bad interface file: dist-install/build/GHC/Classes.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) Full log: $ tar jxf ghc-7.4.1-i386-unknown-linux.tar.bz2 $ cd ghc-7.4.1/ tibell@tibell:ghc-7.4.1$ ./configure --prefix=/usr/local checking for path to top of build tree... /tmp/ghc-7.4.1 Build platform inferred as: i386-unknown-linux Host platform inferred as: i386-unknown-linux Target platform inferred as: i386-unknown-linux GHC build : i386-unknown-linux GHC host : i386-unknown-linux GHC target : i386-unknown-linux checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for gsed... sed checking for gcc... /usr/bin/gcc checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking version of gcc... 4.4.3 checking how to run the C preprocessor... /usr/bin/gcc -E checking whether ld understands --hash-size=31... checking whether ld understands --reduce-memory-overheads... checking for extra options to pass gcc when compiling via C... -fwrapv checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking for .subsections_via_symbols... no checking for GNU non-executable stack support... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking size of void *... 8 checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... yes checking for ar arguments... q checking whether ranlib is needed... no configure: creating ./config.status config.status: creating settings config.status: creating mk/config.mk config.status: creating mk/install.mk **************************************************** Configuration done, ready to 'make install' (see README and INSTALL files for more info.) **************************************************** $ sudo make install make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES /usr/bin/install -c -m 755 -d "/usr/local/share/man" /usr/bin/install -c -m 755 -d "/usr/local/share/man/man1" /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1" "rm" -f driver/split/dist/ghc-split echo '#!/usr/bin/perl' >> driver/split/dist/ghc-split echo '$TARGETPLATFORM = "i386-unknown-linux";' >> driver/split/dist/ghc-split echo '$TABLES_NEXT_TO_CODE = "YES";' >> driver/split/dist/ghc-split cat driver/split/dist/ghc-split.prl >> driver/split/dist/ghc-split /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1" /usr/bin/install -c -m 755 driver/split/dist/ghc-split "/usr/local/lib/ghc-7.4.1" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/ghci-7.4.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/ghci-7.4.1" echo '#!/bin/sh' >> "/usr/local/bin/ghci-7.4.1" echo 'exec "/usr/local/bin/ghc-7.4.1" --interactive ${1+"$@"}' >> "/usr/local/bin/ghci-7.4.1" chmod +x "/usr/local/bin/ghci-7.4.1" "rm" -f "/usr/local/bin/ghci" ln -s ghci-7.4.1 "/usr/local/bin/ghci" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include/." && /usr/bin/install -c -m 644 includes/./*.h "/usr/local/lib/ghc-7.4.1/include/./" && /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/usr/local/lib/ghc-7.4.1/include/rts/" && /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/usr/local/lib/ghc-7.4.1/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/usr/local/lib/ghc-7.4.1/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/usr/local/lib/ghc-7.4.1/include/stg/" && true /usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/dist-ghcconstants/header/GHCConstants.h includes/dist-derivedconstants/header/DerivedConstants.h "/usr/local/lib/ghc-7.4.1/include/" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/include" /usr/bin/install -c -m 644 rts/dist/build/ffi.h rts/dist/build/ffitarget.h "/usr/local/lib/ghc-7.4.1/include/" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/haddock-ghc-7.4.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/haddock-ghc-7.4.1" echo '#!/bin/sh' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'exedir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'exeprog="haddock"' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'executablename="$exedir/$exeprog"' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'datadir="/usr/local/share"' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'bindir="/usr/local/bin"' >> "/usr/local/bin/haddock-ghc-7.4.1" echo 'topdir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/haddock-ghc-7.4.1" cat utils/haddock/haddock.wrapper >> "/usr/local/bin/haddock-ghc-7.4.1" chmod +x "/usr/local/bin/haddock-ghc-7.4.1" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/html/" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/html/Classic.theme/" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/latex/" /usr/bin/install -c -m 644 utils/haddock/html/frames.html "/usr/local/lib/ghc-7.4.1/html/" /usr/bin/install -c -m 644 utils/haddock/html/haddock-util.js "/usr/local/lib/ghc-7.4.1/html/" /usr/bin/install -c -m 644 utils/haddock/html/Classic.theme/haskell_icon.gif "/usr/local/lib/ghc-7.4.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/html/Classic.theme/minus.gif "/usr/local/lib/ghc-7.4.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/html/Classic.theme/plus.gif "/usr/local/lib/ghc-7.4.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/html/Classic.theme/xhaddock.css "/usr/local/lib/ghc-7.4.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/html/Ocean.std-theme/hslogo-16.png "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 644 utils/haddock/html/Ocean.std-theme/minus.gif "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 644 utils/haddock/html/Ocean.std-theme/ocean.css "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 644 utils/haddock/html/Ocean.std-theme/plus.gif "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 644 utils/haddock/html/Ocean.std-theme/synopsis.png "/usr/local/lib/ghc-7.4.1/html/Ocean.std-theme/" /usr/bin/install -c -m 644 utils/haddock/latex/haddock.sty "/usr/local/lib/ghc-7.4.1/latex/" "rm" -f "/usr/local/bin/haddock" ln -s haddock-ghc-7.4.1 "/usr/local/bin/haddock" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/hsc2hs" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/hsc2hs" echo '#!/bin/sh' >> "/usr/local/bin/hsc2hs" echo 'exedir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/hsc2hs" echo 'exeprog="hsc2hs"' >> "/usr/local/bin/hsc2hs" echo 'executablename="$exedir/$exeprog"' >> "/usr/local/bin/hsc2hs" echo 'datadir="/usr/local/share"' >> "/usr/local/bin/hsc2hs" echo 'bindir="/usr/local/bin"' >> "/usr/local/bin/hsc2hs" echo 'topdir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/hsc2hs" echo 'HSC2HS_EXTRA="--cflag=-fno-stack-protector "' >> "/usr/local/bin/hsc2hs" cat utils/hsc2hs/hsc2hs.wrapper >> "/usr/local/bin/hsc2hs" chmod +x "/usr/local/bin/hsc2hs" /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/usr/local/lib/ghc-7.4.1" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/ghc-pkg-7.4.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/ghc-pkg-7.4.1" echo '#!/bin/sh' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'exedir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'exeprog="ghc-pkg"' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'executablename="$exedir/$exeprog"' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'datadir="/usr/local/share"' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'bindir="/usr/local/bin"' >> "/usr/local/bin/ghc-pkg-7.4.1" echo 'topdir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/ghc-pkg-7.4.1" cat utils/ghc-pkg/ghc-pkg.wrapper >> "/usr/local/bin/ghc-pkg-7.4.1" chmod +x "/usr/local/bin/ghc-pkg-7.4.1" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/ghc-pkg" ln -s ghc-pkg-7.4.1 "/usr/local/bin/ghc-pkg" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/runghc" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/runghc" echo '#!/bin/sh' >> "/usr/local/bin/runghc" echo 'exedir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/runghc" echo 'exeprog="runghc"' >> "/usr/local/bin/runghc" echo 'executablename="$exedir/$exeprog"' >> "/usr/local/bin/runghc" echo 'datadir="/usr/local/share"' >> "/usr/local/bin/runghc" echo 'bindir="/usr/local/bin"' >> "/usr/local/bin/runghc" echo 'topdir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/runghc" cat utils/runghc/runghc.wrapper >> "/usr/local/bin/runghc" chmod +x "/usr/local/bin/runghc" "rm" -f "/usr/local/bin/runhaskell" ln -s runghc "/usr/local/bin/runhaskell" /usr/bin/install -c -m 755 -d "/usr/local/bin" "rm" -f "/usr/local/bin/ghc-7.4.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/usr/local/bin/ghc-7.4.1" echo '#!/bin/sh' >> "/usr/local/bin/ghc-7.4.1" echo 'exedir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/ghc-7.4.1" echo 'exeprog="ghc-stage2"' >> "/usr/local/bin/ghc-7.4.1" echo 'executablename="$exedir/$exeprog"' >> "/usr/local/bin/ghc-7.4.1" echo 'datadir="/usr/local/share"' >> "/usr/local/bin/ghc-7.4.1" echo 'bindir="/usr/local/bin"' >> "/usr/local/bin/ghc-7.4.1" echo 'topdir="/usr/local/lib/ghc-7.4.1"' >> "/usr/local/bin/ghc-7.4.1" echo 'executablename="$exedir/ghc"' >> "/usr/local/bin/ghc-7.4.1" cat ghc/ghc.wrapper >> "/usr/local/bin/ghc-7.4.1" chmod +x "/usr/local/bin/ghc-7.4.1" "rm" -f "/usr/local/bin/ghc" ln -s ghc-7.4.1 "/usr/local/bin/ghc" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1" for i in driver/ghc-usage.txt driver/ghci-usage.txt rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc7.4.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc7.4.1.so rts/dist/build/libHSrts_thr-ghc7.4.1.so rts/dist/build/libHSrts_thr_debug-ghc7.4.1.so rts/dist/build/libffi.so rts/dist/build/libffi.so.5 rts/dist/build/libffi.so.5.0.10 settings; do \ case $i in \ *.a) \ /usr/bin/install -c -m 644 $i "/usr/local/lib/ghc-7.4.1"; \ true /usr/local/lib/ghc-7.4.1/`basename $i` ;; \ *.dll) \ /usr/bin/install -c -m 644 -s $i "/usr/local/lib/ghc-7.4.1" ;; \ *.so) \ /usr/bin/install -c -m 755 $i "/usr/local/lib/ghc-7.4.1" ;; \ *.dylib) \ /usr/bin/install -c -m 755 $i "/usr/local/lib/ghc-7.4.1";; \ *) \ /usr/bin/install -c -m 644 $i "/usr/local/lib/ghc-7.4.1"; \ esac; \ done /usr/bin/gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/usr/local/lib/ghc-7.4.1"' -DINCLUDE_DIR='"/usr/local/lib/ghc-7.4.1/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -x c -Iincludes rts/package.conf.in -o rts/package.conf.install.raw grep -v '^#pragma GCC' rts/package.conf.install.raw | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/package.conf.install /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1" for i in utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist-install/build/tmp/hsc2hs utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/runghc/dist-install/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2; do \ /usr/bin/install -c -m 755 $i "/usr/local/lib/ghc-7.4.1"; \ done "mv" "/usr/local/lib/ghc-7.4.1/ghc-stage2" "/usr/local/lib/ghc-7.4.1/ghc" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1" "rm" -rf "/usr/local/lib/ghc-7.4.1/package.conf.d" /usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-7.4.1/package.conf.d" "/usr/local/lib/ghc-7.4.1/ghc-pkg" --force --global-conf "/usr/local/lib/ghc-7.4.1/package.conf.d" update rts/package.conf.install Reading package info from "rts/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal" install "/usr/local/lib/ghc-7.4.1/ghc" "/usr/local/lib/ghc-7.4.1/ghc-pkg" "strip" "/usr/local/lib/ghc-7.4.1" libraries/ghc-prim dist-install '' '/usr/local' '/usr/local/lib/ghc-7.4.1' '/usr/local/share/doc/ghc/html/libraries' NO Installing library in /usr/local/lib/ghc-7.4.1/ghc-prim-0.2.0.0 ghc-cabal: Bad interface file: dist-install/build/GHC/Classes.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 -- Johan

5 8

seemingly inconsistent behavior for "kind-indexed" type constraints in GHC 7.6
by Nicolas Frisby 08 Oct '12

08 Oct '12

GHC 7.6 is rejecting some programs that I think ought to be well-typed. Details here https://gist.github.com/3842579 I find this behavior particularly odd because I can get GHC to deduce the type equalities in some contexts but not in others. In particular, it does not deduce them inside of type class instances. Is this a known issue? I'll create a Trac ticket if that's appropriate. Thanks for your time.

3 7

Constructing TH types
by Eric M. Pashman 06 Oct '12

06 Oct '12

Hello, I'm using Template Haskell (which I've just begun to learn) to do "stanamic" type-checking. Basically I'm just converting 'TypeRep' and 'TyCon' values (from 'Data.Typeable') into Template Haskell's representation (i.e., values of the 'Type' datatype) and splicing them as type signatures in code where compile-time type inference is otherwise impossible. My first thought was simply to make a TH 'Name' from the 'show' representation of a 'TypeRep', and turn that into a 'Type': toType :: TypeRep -> Type toType = ConT . mkName . show This works for simple, atomic types like 'Int', but it chokes on compound types (I mean those with a type parameter, e.g. 'Maybe Int'.), for reasons I don't quite understand. So I tried this instead: toType tr = foldr (flip AppT . toType) (tcToType tc) trs where (tc, trs) = splitTyConApp tr tcToType :: TyCon -> Type tcToType = ConT . mkName . show This works for both simple types and compound types made from standard prefix type-constructors, but it breaks on sugared constructors like '[]'; a 'TypeRep' for, say, '[Int]' gets turned into an invalid type that spliced in as '[] Int'. Basically I don't quite understand how 'Name' construction and binding works. Is there a better way to make a 'Name' that will work with sugared type constructors, or do I have to special-case them while doing something like the above? (If so, what are all the special cases? Anything beyond lists and tuples?) Alternative approaches and general tips and hints are welcome as well. I'm fairly new to Haskell in general. Regards, Eric PS: To compile the code above, you just need these imports: import Language.Haskell.TH import Data.Typeable (TyCon, TypeRep, splitTyConApp) Here are some test cases: import Data.Typeable (typeOf) tr0 = typeOf (undefined :: Int) -- Simple tr1 = typeOf (undefined :: Maybe Int) -- Compound, infix tr = typeOf (undefined :: [Int]) -- Compound, sugared

1 0

Comments on current TypeHoles implementation
by Sean Leather 05 Oct '12

05 Oct '12

Hi Simon, Thanks for all your work in getting TypeHoles into HEAD. We really appreciate it. I was playing around with HEAD today and wanted to share a few observations. (1) One of the ideas we had was that a hole `_' would be like `undefined' but with information about the type and bindings. But in the current version, there doesn't appear to be that connection. This mainly applies to ambiguous type variables. Consider: > f = show _ The hole has type a0. But with > f = show undefined there is a type error because a0 is ambiguous. We were thinking that it would be better to report the ambiguous type variable first, rather than the hole. In that case, tou can use -fdefer-type-errors to defer the error. Currently, you don't have that option. I can see the argument either way, however, and I'm not sure which is better. (2) There is a strange case where an error is not reported for a missing type class instance, even though there is no (apparent) relation between the missing instance and the hole. (This also relates to the connection to `undefined', but less directly.) We have the following declaration: > data T = T Int {- no Show instance -} With a hole in the field > g = show (T _) we get a message that the hole has type Int. With > g = show (T undefined) we get an error for the missing instance of `Show T'. (3) In GHCi, I see that the type of the hole now defaults. This is not necessarily bad, though it's maybe not as useful as it could be. ghci> :t show _ reports that the hole has type (). (4) In GHCi, sometimes a hole throws an exception, and sometimes it does not. ghci> show _ throws an exception with the hole warning message ghci> show (T _) and ghci> _ + 42 cause GHCi to panic. (5) There are some places where unnecessary parentheses are used when pretty-printing the code: ghci> :t _ _ <interactive>:1:1: Warning: Found hole `_' with type t0 -> t Where: `t0' is a free type variable `t' is a rigid type variable bound by the inferred type of it :: t at Top level In the expression: _ In the expression: _ (_) <interactive>:1:3: Warning: Found hole `_' with type t0 Where: `t0' is a free type variable In the first argument of `_', namely `_' In the expression: _ (_) _ _ :: t The argument `_' does not need to be printed as `(_)'. There is also the small matter, in this example, of distinguishing which `_' is which. The description works, but you have to think about it. I don't have an immediate and simple solution to this. Perhaps the addition of unique labels (e.g. _$1 _$2). But this is not a major problem. It can even wait until some future development/expansion on TypeHoles. Regards, Sean

7 13

TypeHoles: errors, warnings, and deferring
by Sean Leather 05 Oct '12

05 Oct '12

(I'm starting a new thread to focus on just this issue.) On Thu, Oct 4, 2012 at 11:33 AM, Simon Peyton-Jones wrote: > (2) There is a strange case where an error is not reported for a > missing type class instance, even though there is no (apparent) relation > between the missing instance and the hole. (This also relates to > the connection to `undefined', but less directly.) > > ** > > ** ** > > Yes; GHC classifies type errors into two groups:**** > > **· **insoluble (eg Int~Bool) are definitely wrong**** > > **· **unsolved (eg Eq a) might be ok if (say) the context changed* > *** > > If there are any insolubles (anywhere), error messages about unsolved > constraints are suppressed. This is usually good; it focuses your > attention on definite errors first. Let’s call the suppressed errors > “suppressed erorrs”.**** > > ** ** > > Now, holes are classified as “insoluble” at the moment, and that’s why all > other unsolved errors are suppressed.**** > > ** ** > > ** ** > > At the moment, if you way –XTypeHoles you get only a *warning *even > though it’s really an error. Moreover it’s weird that the * warning*suppresses other > *error* messages.**** > > ** ** > > So I propose to change it so that –XTypeHoles gives an error message (for > holes); and you can use –fdefer-type-errors to defer it.**** > > ** ** > > In doing this I also realised that with –fdefer-type-errors you only get > warnings for the things that would previously have been errors; you don’t > get warnings for “supressed errors”. And that’s arguably bad, since you > don’t know about all the errors you are deferring to runtime. So I’ve > changed it so that with –fdefer-type-errors you get **all** errors as > warnings (no supression). > How do we report holes? As errors or warnings? What happens to other type errors and warnings? The following is the "ideal" approach that Thijs and I propose: 1. A hole report is a warning. 2. Any type error "caused" by a hole is also a warning. 3. All other type errors are treated normally (e.g. errors are not deferred unless -fdefer-type-errors is used, insoluble errors suppress unsolved, and errors suppress warnings). This approach provides the greatest convenience, the most useful information, and the least surprise: - *Convenience*: You don't need -fdefer-type-errors when working with holes. One of our goals was to allow you to focus on the holes while trusting the program to be well-typed. Consequently, you use -fdefer-type-errors only if you want *all* errors to be deferred. - *Information*: You get more information by including the type errors caused by the hole. For example, the type of the hole in `show _` (e.g. `a0'), is not that useful on its own, but the additional warning of the missing instance (`Show a0`) is quite useful. If you were to suppress this warning, we would be missing crucial evidence for what you could use to fill the hole. - *Surprise*: If you replace a hole with `undefined' in the current implementation, you would be surprised by suddenly seeing new errors that you might not expect. If all of those errors were instead treated as warnings with the hole present, you would know what to expect. We think the only type errors that fit the category of "being caused by a hole" are unsolved constraints. That includes `show _' plus even examples such as the following: > f :: a -> a > f x = x _ Currently, this only prints the hole warning, presumably because there are no constraints on `a'. Note that determining the unsolved constraints caused by a hole may be an approximation. For example, consider the following code: > data T a = T a > instance Show (T Int) -- flexible instance > g = show (T _) We can see that the hole is the "cause" for the unsolved constraint, but the type of the hole (`a0') is not in the top level of the constraint (`Show (T a0)'). It may be that this remains an unsolved error. I think that's acceptable. You could view our description of a hole as an `undefined' with locally-deferred type errors. This is clearly treating a hole as a different sort of error. It doesn't seem to immediately fit into one of the two groups: insoluble and unsolved. A hole warning doesn't suppress other errors, but it could cause some unsolved errors to become warnings. I don't think a hole will lead to any insoluble errors. If that's true, perhaps it should not be considered insoluble itself. Perhaps a hole could be considered a special form of unsolved error. I'm not sure if our proposal fits nicely into GHC's design, but we think it provides the best approach from a user's perspective. Regards, Sean

1 0

Re: memory fragmentation with ghc-7.6.1
by Ben Gamari 01 Oct '12

01 Oct '12

Simon Marlow <marlowsd(a)gmail.com> writes: > On 28/09/12 17:36, Ben Gamari wrote: >> Unfortunately, after poking around I found a few obvious problems with >> both the code and my testing configuration which explained the >> performance drop. Things seem to be back to normal now. Sorry for the >> noise! Great job on the new codegen. > > That's good to hear, thanks for letting me know! > Of course! That being said, I have run in to a bit of a performance issue which could be related to the runtime system. In particular, as I scale up in thread count (from 6 up to 48, the core count of the machine) in my program[1] (test data available), I'm seeing the total runtime increase, as well as a corresponding increase in CPU-seconds used. This despite the RTS claiming consistently high (~94%) productivity. Meanwhile Threadscope shows that nearly all of my threads are working busily with very few STM retries and no idle time. This in an application which should scale reasonably well (or so I believe). Attached below you will find a crude listing of various runtime statistics over a variety of thread counts (ranging into what should probably be regarded as the absurdly large). The application is a parallel Gibbs sampler for learning probabilistic graphical models. It involves a set of worker threads (updateWorkers) pulling work units off of a common TQueue. After grabbing a work unit, the thread will read a reference to the current global state from an IORef. It will then begin a long-running calculation, resulting in a small value (forced to normal form with deepseq) which it then communicates back to a global update thread (diffWorker) in the form of a lambda through another TQueue. The global update thread then maps the global state (the same as was read from the IORef earlier) through this lambda with atomicModifyIORef'. This is all implemented in [2]. I do understand that I'm asking a lot of the language and I have been quite impressed by how well Haskell and GHC have stood up to the challenge thusfar. That being said, the behavior I'm seeing seems a bit strange. If synchronization overhead were the culprit, I'd expect to observe STM retries or thread blocking, which I do not see (by eye it seems that STM retries occur on the order of 5/second and worker threads otherwise appear to run uninterrupted except for GC; GHC event log from a 16 thread run available here[3]). If GC were the problem, I would expect this to be manifested in the productivity, which it is clearly not. Do you have any idea what else might be causing such extreme performance degradation with higher thread counts? I would appreciate any input you would have to offer. Thanks for all of your work! Cheers, - Ben [1] https://github.com/bgamari/bayes-stack/v2 [2] https://github.com/bgamari/bayes-stack/blob/v2/BayesStack/Core/Gibbs.hs [3] http://goldnerlab.physics.umass.edu/~bgamari/RunCI.eventlog Performance of Citation Influence model on lda-handcraft data set 1115 arcs, 702 nodes, 50 items per node average 100 sweeps in blocks of 10, 200 topics Running with +RTS -A1G ghc-7.7 9c15249e082642f9c4c0113133afd78f07f1ade2 Cores User time (s) Walltime (s) CPU % Productivity ====== ============= ============= ====== ============= 2 488.66 269.41 188% 93.7% 3 533.43 195.28 281% 94.1% 4 603.92 166.94 374% 94.3% 5 622.40 138.16 466% 93.8% 6 663.73 123.00 558% 94.2% 7 713.96 114.17 647% 94.0% 8 724.66 101.98 736% 93.7% 9 802.75 100.59 826% . 10 865.05 97.69 917% . 11 966.97 99.09 1010% . 12 1238.42 114.28 1117% 13 1242.43 106.53 1206% 14 1428.59 112.48 1310% 15 1299.40 97.52 1387% 16 1559.99 108.86 1481% 17 1972.02 126.49 1604% 18 2157.03 130.91 1696% 19 1966.24 115.29 1770% . 20 2693.64 146.76 1887% . 21 3051.16 158.48 1990% . 22 4100.88 199.18 2109% 93.7% 23 4156.94 193.38 2201% 93.5% 24 4780.46 212.13 2303% 94.3% 25 5733.64 242.78 2407% . 26 7806.47 313.92 2526% . 27 6368.32 249.65 2596% . 28 8563.18 320.26 2717% -sstderr output from 2 cores: ====================================== 214,358,463,960 bytes allocated in the heap 2,261,367,592 bytes copied during GC 71,053,384 bytes maximum residency (7 sample(s)) 2,077,816 bytes maximum slop 2299 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 100 colls, 100 par 28.58s 14.27s 0.1427s 0.3345s Gen 1 7 colls, 6 par 3.36s 1.74s 0.2486s 0.3241s Parallel GC work balance: 25.06% (serial 0%, perfect 100%) TASKS: 4 (1 bound, 3 peak workers (3 total), using -N2) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.03s ( 0.03s elapsed) MUT time 474.28s (252.98s elapsed) GC time 31.94s ( 16.01s elapsed) EXIT time 0.12s ( 0.12s elapsed) Total time 506.49s (269.26s elapsed) Alloc rate 451,969,681 bytes per MUT second Productivity 93.7% of total user, 176.2% of total elapsed gc_alloc_block_sync: 108391 whitehole_spin: 0 gen[0].sync: 7392 gen[1].sync: 97126 -sstderr output from 24 cores: ======================================= 262,335,150,000 bytes allocated in the heap 1,323,818,912 bytes copied during GC 67,648,048 bytes maximum residency (7 sample(s)) 2,927,176 bytes maximum slop 25172 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 29 colls, 29 par 162.40s 6.77s 0.2335s 0.3469s Gen 1 7 colls, 6 par 118.34s 5.32s 0.7600s 1.2448s Parallel GC work balance: 5.61% (serial 0%, perfect 100%) TASKS: 27 (1 bound, 26 peak workers (26 total), using -N24) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.34s ( 0.34s elapsed) MUT time 4606.75s (197.59s elapsed) GC time 280.74s ( 12.09s elapsed) EXIT time 0.40s ( 0.40s elapsed) Total time 4888.61s (210.80s elapsed) Alloc rate 56,945,837 bytes per MUT second Productivity 94.3% of total user, 2185.8% of total elapsed gc_alloc_block_sync: 5397994 whitehole_spin: 0 gen[0].sync: 32282 gen[1].sync: 5072

3 2