- ghc-devs - Haskell.org

Request: export runTcInteractive from TcRnDriver
by p.k.f.holzenspies＠utwente.nl 12 Mar '14

12 Mar '14

Dear GHC-devs, Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.) I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;) Regards, Philip

3 3

Getting warnings when pushing to git.haskell.org
by Johan Tibell 11 Mar '14

11 Mar '14

Hi, I get the following warning every time I push to git.haskell.org. Anyone have an idea what the correct fix is? $ git push origin master perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LANG = (unset) are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Counting objects: 13, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 652 bytes | 0 bytes/s, done. Total 7 (delta 6), reused 0 (delta 0) remote: performing tab-check... remote: perl: warning: Setting locale failed. remote: perl: warning: Please check that your locale settings: remote: LANGUAGE = (unset), remote: LC_ALL = (unset), remote: LC_CTYPE = "UTF-8", remote: LANG = (unset) remote: are supported and installed on your system. remote: perl: warning: Falling back to the standard locale ("C"). remote: mirroring ssh://git@git.haskell.org/ghc to ssh:// git@github.com/ghc/ghc ... remote: To ssh://git@github.com/ghc/ghc remote: 22e4bba..d8b3826 master -> master remote: running notifier To ssh://git@git.haskell.org/ghc.git 22e4bba..d8b3826 master -> master

2 1

Safe Haskell
by Simon Peyton Jones 11 Mar '14

11 Mar '14

David Any views about https://ghc.haskell.org/trac/ghc/ticket/8827? We propose to remove the recursive check (see the ticket for what that means). Simon

1 0

Template Haskell of GHC 7.8 (again)
by Kazu Yamamoto 11 Mar '14

11 Mar '14

Hi, With the attached file, say Printf.hs, GHCi 7.6.3 works as follows: % ghci Printf.hs [1 of 1] Compiling Printf ( Printf.hs, interpreted ) Ok, modules loaded: Printf. > :set -XTemplateHaskell > putStrLn ( $(pr "Hello") ) Hello "Hello" is printed. Good. However, with GHC 7.8, the following error occurs: % ghci Printf.hs [1 of 1] Compiling Printf ( Printf.hs, interpreted ) Ok, modules loaded: Printf. > :set -XTemplateHaskell > putStrLn ( $(pr "Hello") ) unknown package: main Is this a bug of Template Haskell of GHC 7.8? --Kazu {-# LANGUAGE TemplateHaskell #-} -- -- derived from: http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht… -- module Printf (pr) where import Language.Haskell.TH data Format = D | S | L String parse :: String -> [Format] parse s = [ L s ] gen :: [Format] -> Q Exp gen [D] = [| \n -> show n |] gen [S] = [| \s -> s |] gen [L s] = stringE s -- | -- -- >>> :set -XTemplateHaskell -- >>> putStrLn ( $(pr "Hello") ) -- Hello pr :: String -> Q Exp pr s = gen (parse s)

2 3

Template Haskell of GHC 7.8
by Kazu Yamamoto 11 Mar '14

11 Mar '14

Hi, The tests for doctest are not passed again with GHC 7.8: ---- 17) Property.runProperty reports the values for which a property that takes multiple arguments fails expected: ["False","0","\"\""] but got: ["<interactive>:24:66:"," \8216doctest_prop\8217 is not in the type environment at a reify"," In the splice: $(polyQuickCheck 'doctest_prop)"] ---- This comes from: ----src/Property.hs where quickCheck term vars = "let doctest_prop " ++ unwords vars ++ " = " ++ term ++ " in $(polyQuickCheck 'doctest_prop)" ---- It seems to me that the behavior of GHC 7.8's Template Haskell changed. Would you tell me how to fix this? --Kazu

1 1

Card marking for newly allocated arrays
by Johan Tibell 10 Mar '14

10 Mar '14

Hi, For MutableArray#s, a card is supposed to be marked if the array is pointing to an object in a younger generation than itself resides in. Since the array always points to elements in the same or an older generation when it gets allocated, we should be fine with marking the array as clean upon allocation and setting all the cards to zero. Right now it's marked as *dirty* and all cards are (modulo a bug) marked as zero. I think we should mark these arrays as clean to avoid some GC costs later. We could avoid writing the card table on allocation as well, as it's always safe to default to dirty. However, this will incur extra GC costs later (after the first write to the array) as the whole array will appear as dirty (due to garbage values in the card table as it wasn't initialized) even if only a single element was written. I'm leaning towards 1) marking arrays as clean and 2) zeroing out the card table when the array is created. Thoughts? -- Johan

2 1

Optimized Cmm containing useless blocks
by Johan Tibell 10 Mar '14

10 Mar '14

While looking at some generated Cmm I saw things like this c1Cm: goto c1Cq; c1Cq: i.e. useless basic blocks that haven't been optimized away. Is this to be expected? -- Johan

5 7

Building GHC for performance testing
by Johan Tibell 08 Mar '14

08 Mar '14

Hi, I'd like to set up a performance build bot for GHC, but before I can do that I need a script that reliably builds GHC and runs nofib. Do we have such a script? Here's a strawman proposal for one: cabal install happy alex git clone git://git.haskell.org/ghc.git cd ghc ./sync-all --nofib get perl boot ./configure make cd nofib make clean make boot make -k mode=slow Questions: * Does this look sensible? * Is there a way to only build and run a subset of the benchmarks? * Are there any tweaks to mk/build.mk we can do to make the build faster without compromising the results? * Is there a way to do this in a cheap throwaway VM like travis-ci does? Could such a VM already provide GHC and the required libs to make the whole thing hermetic?

6 9

libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
by Mateusz Kowalczyk 08 Mar '14

08 Mar '14

Hi, I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include "HsIntegerGmp.h" ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x 5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x 5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x 5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? -- Mateusz K.

2 4

RE: new Windows build problem
by Simon Peyton Jones 07 Mar '14

07 Mar '14

Actually, the two problems seem to be the same. A fresh build from scratch yields libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault Then sniping the command line that tried to build Random.o yields "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/. -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.2 -O2 -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -dcore-lint -no-user-package-db -rtsopts -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device io So this ioctl thing seems to be reported as a seg fault by the make system. Running the same command from a 'cmd' window does give a seg-fault pop-up window. Alas. Running with -dshow-passes shows that it happens during code generation, *** CorePrep: Result size of CorePrep = {terms: 1,214, types: 912, coercions: 52} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: I am totally stuck. Simon From: Simon Peyton Jones Sent: 06 March 2014 22:11 To: ghc-devs(a)haskell.org Subject: new Windows build problem Sigh. Totally new problem with building GHC (HEAD) on Windows.. "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name haskell98-2.0.0.3 -hide-all-packages -i -ilibraries/haskell98/. -ilibraries/haskell98/dist-install/build -ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/dist-install/build -Ilibraries/haskell98/dist-install/build/autogen -Ilibraries/haskell98/. -optP-include -optPlibraries/haskell98/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package directory-1.2.0.2 -package old-locale-1.0.0.6 -package old-time-1.1.0.2 -package process-1.2.0.0 -package time-1.4.2 -Wall -XHaskell98 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -dcore-lint -no-user-package-db -rtsopts -odir libraries/haskell98/dist-install/build -hidir libraries/haskell98/dist-install/build -stubdir libraries/haskell98/dist-install/build -c libraries/haskell98/./Directory.hs -o libraries/haskell98/dist-install/build/Directory.o bash: [6536: 1 (255)] tcsetattr: Inappropriate ioctl for device HEAD $ What on earth is this ioctl stuff? The above is repeatable; same command line, same result. But I'm also getting random seg-faults when building libraries with the stage2 compiler libraries/random/ghc.mk:5: recipe for target 'libraries/random/dist-install/build/System/Random.o' failed make[1]: *** [libraries/random/dist-install/build/System/Random.o] Segmentation fault This is NOT repeatable. Saying 'make' again gets further. Any ideas? Simon

2 2