May 2013 - ghc-devs - Haskell.org

Re: [commit: testsuite] master: Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES (b32d38a)
by Páli Gábor János 12 May '13

12 May '13

On Fri, May 10, 2013 at 3:40 PM, Ian Lynagh <igloo(a)earth.li> wrote: > Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES > > We were checking paths with > if [ -f '"/path/to/Prelude"' ] > i.e. the " quotes were being quoted by the ' quotes. Now we just > use " quotes (which come from the ghc-pkg output). This does not work (again) on the FreeBSD builder clients. Any suggestions where else to fix this problem for them then?

2 6

Safe Haskell validate failure
by Simon Peyton-Jones 10 May '13

10 May '13

When running validate I got these failures (below) from Safe Haskell. Unexpected failures: ghci/scripts Defer02 [bad stderr] (ghci) indexed-types/should_fail T7786 [stderr mismatch] (normal) perf/compiler T3064 [stat too good] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal) But when I manually did cd testsuite/tests/safeHaskell/check make all went fine. Everything passed. Could this be a parallel-make synch problem or something? Or a make-clean problem? Simon =====> ImpSafeOnly01(normal) 1163 of 3620 [0, 0, 0] cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly01 VANILLA=--disable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared Wrong exit code (expected 0 , actual 2 ) Stdout: pdb.safePkg01/local.db: safePkg01-1.0 trusted: False M_SafePkg Stderr: pdb.safePkg01/dist/build/M_SafePkg.hi: openBinaryFile: does not exist (No such file or directory) make[3]: *** [safePkg01] Error 1 *** unexpected failure for safePkg01(normal) cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory cleanPackageDatabase.safePkg01 =====> ImpSafeOnly02(normal) 1164 of 3620 [0, 1, 0] cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly02 VANILLA=--disable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared cd ./safeHaskell/check/pkg01 && '/5playpen/simonpj/HEAD/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c ImpSafeOnly01.hs -fpackage-trust -package-db pdb.ImpSafeOnly01/local.db -trust base >ImpSafeOnly01.comp.stderr 2>&1 Compile failed (status 256) errors were: ImpSafeOnly01.hs:4:1: Failed to load interface for ‛M_SafePkg’ There are files missing in the ‛safePkg01-1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. *** unexpected failure for ImpSafeOnly01(normal)

5 5

changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)
by Carter Schonwald 10 May '13

10 May '13

hey All, I'm starting to dig into what are tasks i could do to help contribute to ghc, and also let me further familiarize myself with the code base so that i can later undertake more ambitious contributions. One relatively simple task that I think might be valuable would be to have cas be a cmm primop on the llvm backend. Doing so would simplify porting ghc to new architectures supported by llvm, AND I believe that it might improve ghc haskell performance on certain concurrent workloads, because currently the compare and exchange op isn't inlined into functions using it, such as atomicModifyMutVar, so theres a c call to cas in an otherwise pretty tight loop. It would also potentially pave the way to providing other interesting atomicity primitives leveraging llvm too. (I think) heres the ticket i've open on this matter http://hackage.haskell.org/trac/ghc/ticket/7883 This is something I'd be interested in doing as a warmup project, though i'll need help benchmarking if theres any performance improving on heavy concurrent work loads, as I don't have access to beefy hardware presently. is this sort of exploratory engineering / change something that the community / ghc devs are open to? (I'd like to make sure any wee starter project I do to get my feet wet has some potential to actually get merged into ghc should it work out) it looks like it'd be a relatively tractable first project that touches a lot of the backend bits on ghc too, which would be interesting. thanks and any feedback/ideas/suggestions would be wonderful / appreciated -Carter

4 3

Turning on -funbox-small-strict-fields by default in GHC 7.8
by Johan Tibell 10 May '13

10 May '13

Hi, I like to discuss enabling -funbox-small-strict-fields by default in GHC 7.8. First, a short description of the flag and why I added it. *What does the flag do?* The flag causes all strict, pointer-sized or smaller* fields to be unpacked, as if you preceded them by an UNPACK pragma. *Why does the flag exist?* The flag doesn't allow you to express anything you couldn't already express using UNPACK/-funbox-strict-fields. The purpose of the flag is twofold: - Allow for less clutter in source code. If you look at code tuned for performance, every single small field has an UNPACK pragma (e.g. see bytestring, text, containers, attoparsec, binary, etc). The extra UNPACK pragmas makes the data type declaration harder to read. - To give better performance by default for beginner and intermediate Haskellers. Almost any performance problem I diagnoes (e.g. on StackOverflow) involve telling the person to use UNPACK (and make the field strict). I'd like to only tell them to make the field strict and let compiler deal with the UNPACK. *How do we turn the flag on by default?* Before we turn the flag on by default, we should convince ourselves that it won't hurt performance (e.g. by causing re-boxing when an unpacked field is passed to a non-strict function). Here's my plan: - Look at all data declarations in some set of core libraries (e.g. the ones mentioned above) and see if there are any strict but not unpacked small fields in there. The presence of such fields suggests that the author decided that unpacking was not beneficial there. *Done:* there are no such fields in bytestring, text, binary, containers, or attoparsec. - Run the nofib suite, which now includes some code with strict fields from the language shootout suite, as a sanity check. - Benchmark some large program that isn't carefully tuned by using strictness in just the right places (like our core libraries tend to be), to make sure this change doesn't hurt performance there. I nomiate GHC as the candidate program for this test. Aside: If I recall correctly John Meacham said that JHC has always used this optimization. Does this sound like a reasonable plan? Does anyone have any input on whether this change makes sense? Simon? P.S. I know how to run nofib with and without the flag. How can I benchmark the impact of the flag on building GHC? Does anyone have a step-by-step recipe for using GHC as a benchmark? * This also includes Double, Int64, and Word64 on 32-bit platforms so the program space usage and performance doesn't change dramatically when switching platforms.

8 14

Handling of NaN
by Jan Stolarek 10 May '13

10 May '13

I need some help with my work on ticket #6135. Consider this program: {-# LANGUAGE BangPatterns, MagicHash #-} module Main where import GHC.Exts main = print $ nan## ==## nan## where !(D# nan##) = 0.0 / 0.0 This prints False, which is a correct implementation of IEEE754 standard. However when I compile this with my modified compiler that uses new comparison primops (they return Int# instead of Bool) I get True, whcih obviously is incorrect. I belive that the problem lies in this piece of code from prelude/PrelRules.hs: mkRelOpRule :: Name -> (forall a . Ord a => a -> a -> Bool) -> [RuleM CoreExpr] -> Maybe CoreRule mkRelOpRule nm cmp extra = mkPrimOpRule nm 2 $ rules ++ extra where rules = [ binaryLit (\_ -> cmpOp cmp) , equalArgs >> -- x `cmp` x does not depend on x, so -- compute it for the arbitrary value 'True' -- and use that result return (if cmp True True then trueVal else falseVal) ] It looks that equalArgs suddenly started to return True, whereas it previously returned False. On the other hand in GHCi I get correct result (False). Can anyone give me a hint why is this happening? Janek

3 9

Building & running NoFib
by Amos Robinson 09 May '13

09 May '13

Hi all, I've just tried running 'make' in nofib and it's not finding ../inplace/bin/ghc-stage2 for some reason. So it tries to execute "/BLAH/ghc/ghc-head/" as if it were ghc (but it's a directory). The error message is: > /bin/sh: /Users/amos/ghc/ghc-head/: is a directory > /bin/sh: line 0: [: -gt: unary operator expected > /bin/sh: line 0: [: -ge: unary operator expected > ... > /Users/amos/ghc/ghc-head/ -H64m -O0 -fasm -O2 -Rghc-timing -package array -H32m -hisuf hi -c Main.hs -o Main.omake[2]: /Users/amos/ghc/ghc-head/: Permission denied I tried on another box - Linux - and had much the same issue. Has anyone seen this before? Any clues what might be wrong? Nofib was building fine on the Linux box a few weeks ago, but I think it stopped working after a sync-all. For now though, I'll just try building with > WithNofibHc=/Users/amos/ghc/ghc-head/inplace/bin/ghc-stage2 make which seems to work. Thanks, Amos

2 1

Stuck again on submodules
by Simon Peyton-Jones 09 May '13

09 May '13

Help! I can't build ghc! I get this utils/ghc-pkg/Main.hs:1160:24: Not in scope: `showSimpleInstalledPackageInfoField' Perhaps you meant `showInstalledPackageInfoField' (imported from Distribution.InstalledPackageInfo) And indeed, my libraries/Cabal is way behind simonpj@cam-05-unx:~/code/HEAD$ cd libraries/Cabal simonpj@cam-05-unx:~/code/HEAD/libraries/Cabal$ git log -1 commit 14c5a3f78c00772cf54c2fd5c920a64d53e6f594 Author: Gabor Greif <ggreif(a)gmail.com> Date: Wed Mar 20 22:27:15 2013 +0100 Fix typos "git submodule status" says 14c5a3f78c00772cf54c2fd5c920a64d53e6f594 libraries/Cabal (1_10_branch_forked-1682-g14c5a3f) 1f9f7175e747aad7c424f5b12be5b95f15286f0b libraries/Win32 (2009-06-25-50-g1f9f717) ...etc In another tree entirely "git submodule status" says b4d0c0... libraries/Cabal which looks right, because that commit does futz with showInstalledPackageInfoField. So it looks as if my main GHC repo somehow has the wrong commit for Cabal. How do I make it right? This is so frustrating. Thanks Simon

4 7

DBCS encoding support on Windows
by Max Bolingbroke 08 May '13

08 May '13

Hi GHCers, I've implemented support in GHC for extra Windows code pages on the branch "dbcs" of the base library. The problem this solves is that currently users of Haskell on a Windows machine running in a locale which uses a double-byte code page such as CP936 (GBK) or CP950 (Big5) cannot properly interact with the Windows console in their native language. Unfortunately code page support is a prerequisite for getting this to work correctly because for all Microsoft's fine talk about Unicode being the future, the Windows console does not seem to support it properly - code pages are the only way to go for console input and output. As the standard Windows locale encodings in many regions, these code pages are also the predominant method of encoding text files in many countries, so they are useful outside the console. The solution is along the lines suggested in http://hackage.haskell.org/trac/ghc/ticket/3977, i.e. we create an iconv-like interface to Window's MultiByteToWideChar and WideCharToMultiByte APIs by the judicious use of binary search. In my branch, these APIs will be used whenever we don't have a built-in native Haskell TextEncoding for the code page (we used to fall back on using latin1 for such code pages). Unless there are any objections I'll merge this into the base library main branch next week. Cheers, Max

2 4

Implementing Strict Core
by Johan Tibell 08 May '13

08 May '13

Hi Simon and Max, I've been thinking about Strict Core quite a bit lately. I'd like to take a stab at implementing it in GHC, if feasible. My motivations for implementing Strict Core are - generating faster code in a more robust manner, and - implementing strictness annotations at the type level in Haskell itself*. Now, I don't know how much work this will be. What's you best time estimate (say, if you would do it vs if I would do it)? My plan would roughly be as follows: 1. Create a branch to develop on. 2. Temporarily delete all the non-essential Core2Core transformations. This will let us get to a place where we have a functional compiler using Strict Core more quickly. 3. Change CoreSyn.Expr to be Strict Core. 4. Plumb the changes through the compiler until it compiles (and passes the tests) again. 5. Once all tests pass, re-add all the Core2Core passes and make them use Strict Core. 6. Rebase the commits so they can be merged nicely into the main branch. How does that sound? * I think this could be one of the most important changes in a long time to help Haskell in the "real world". It gives us a better way to talk about strictness than we have today, reducing time spent on chasing down space leaks. One we have strictness annotations in type, we could experiment with a Strict language pragma to make a whole module call-by-value. Cheers, Johan

9 17

Add Functor/Applicative instances for all Monads in GHC
by David Luposchainsky 08 May '13

08 May '13

Hello GHC devs, due to the formation of the Haskell Prime Committee [1], I am motivated to propose another go at the "Applicative => Monad" issue. Regardless of the future of that proposal, I think some changes required by it are beneficial in any case, namely ensuring that all Monads defined in GHC get Applicative/Functor instances. I've successfully modified toy version of 7.6.3 to include these instances to see how it goes, and as you can imagine the changes are numerous but simple; I don't assume HEAD won't be much different in that respect. However, since this would by my first involvement in a project as large as GHC, I am not quite sure of the procedure to follow, even after reading the corresponding Trac/Wiki pages. I'm assuming the policy here is the same as for the libraries mailing list (hence this email), and upon positive feedback I can open a Trac issue, take ownership, clone, modify, send pull request etc. If there's anything wrong with that approach here please tell me. Greetings, David [1] http://thread.gmane.org/gmane.comp.lang.haskell.general/19796

2 1