- ghc-devs - Haskell.org

Is stage-1 sufficient to run nofib
by Joachim Breitner 23 Oct '17

23 Oct '17

Hi, I guess I could just try it, but maybe someone knows it, or knows what would go wrong… If I run nofib with ghc-stage1 instead of ghc-stage2, I should get the same results, right? (ignoring compilation times here) My hope is that it can speed up perf.haskell.org some more. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 3

splitting metavariables
by Richard Eisenberg 23 Oct '17

23 Oct '17

Hi Simon, I just commented (https://ghc.haskell.org/trac/ghc/ticket/14331#comment:35) about a situation where we call splitFunTys on a type that might be a metavariable. (You don't have to read the comment -- that's just to set the context.) Now that I think of it, we should never call the splitXXX functions on metavariables -- any time we do so is wrong. I suppose it's OK if we, say, call splitTyConApp_maybe on (T alpha beta gamma), because we never look through the metavariables there. But it can't possible be write to call splitTyConApp_maybe on alpha. Do you agree? Should we ASSERT that we don't do this? The tcXXX variants are no different in this regard. Actually, I wonder if we can put the check in just one spot: coreView. Whenever we use coreView, we're about to inspect a type. And we should never be inspecting a metavariable in this way. Richard

2 1

Re: Compiling natively GHC for ARMv7l softabi
by shiftag＠nanotek.info 22 Oct '17

22 Oct '17

> shiftag(a)nanotek.info writes: > >> Hi List, >> >> I would like to install GHC for my CPU which is an ARMv7L Soft-ABI >> NEON FPU. I read some stuff on ARM and GHC related. So it appears that >> an installation is possible but with a RPi. The problem is the stack >> binary which has been compiled for Hard-Float target. So it should not >> be difficult to make it work for my architecture. > > Indeed I suspect you are right; it should be fairly straightforward to > build GHC for your platform. > >> I checked for stack sources (stack-1.5.1.tar.gz) but I have any clue >> about how to compile it. Can you give me an hand ? > > First you will need to build GHC itself. This will be a two-step > process: > > 1. First build a cross-compiler [1] for your ARMv7L target on a machine > with a working GHC (e.g. an amd64 machine). > > 2. Transfer this compiler to your target and use it to build a native > GHC > > Let us know if you have any trouble. > > Cheers, > > - Ben > > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling Thank you. So, I succeed to install GHC on x64 GNU/Linux machine. However, I have an issue at Stage1 while cross-compiling. I have the following error : # make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory utils/deriveConstants/ghc.mk:19: utils/deriveConstants/dist/package-data.mk: No such file or directory utils/genapply/ghc.mk:23: utils/genapply/dist/package-data.mk: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/ghc-boot-th/ghc.mk:3: libraries/ghc-boot-th/dist-boot/package-data.mk: No such file or directory libraries/ghc-boot/ghc.mk:3: libraries/ghc-boot/dist-boot/package-data.mk: No such file or directory libraries/template-haskell/ghc.mk:3: libraries/template-haskell/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: No such file or directory compiler/ghc.mk:584: compiler/stage1/package-data.mk: No such file or directory utils/hsc2hs/ghc.mk:15: utils/hsc2hs/dist/package-data.mk: No such file or directory utils/ghc-pkg/ghc.mk:60: utils/ghc-pkg/dist/package-data.mk: No such file or directory utils/dll-split/ghc.mk:23: utils/dll-split/dist-install/package-data.mk: No such file or directory ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory "/usr/bin/ghc" -H32m -O -Wall \ -optc-Wall -optc-fno-stack-protector \ \ -hide-all-packages \ -package base -package array -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=1,24,2,0 \ -DMIN_VERSION_binary_0_8_0 \ -DBOOTSTRAPPING \ -optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src -DGENERICS \ -ilibraries/filepath \ -ilibraries/hpc \ [53 of 95] Compiling Distribution.PackageDescription ( libraries/Cabal/Cabal/Distribution/PackageDescription.hs, bootstrapping/Distribution/PackageDescription.o ) utils/ghc-cabal/ghc.mk:48: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal' failed make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 I checked Google and I found the following patch : https://ghc.haskell.org/trac/ghc/ticket/8709 But it didn't work. Do you have an idea to fix it ? Cheers

4 20

Wildcards in HsTypes
by Alan & Kim Zimmerman 21 Oct '17

21 Oct '17

It seems to me that HsWildCardInfo is unnecessary. It is defined as newtype HsWildCardInfo pass -- See Note [The wildcard story for types] = AnonWildCard (PostRn pass (Located Name)) -- A anonymous wild card ('_'). A fresh Name is generated for -- each individual anonymous wildcard during renaming And only ever used in data HsType pass ... | HsWildCardTy (HsWildCardInfo pass) Why not just do | HsWildCardTy (PostRn pass (Located Name)) ? Am I missing something? Alan

1 0

More windows
by Simon Peyton Jones 20 Oct '17

20 Oct '17

Now in my Windows build, staring with "sh validate -fast -no-clean" I get [230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o ) [231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o ) [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 Simply repeating, thus "sh validate -fast", I then get the same error /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ total 0 /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 But trying "sh validate -fast" once more succeeds: /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe "inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg" --package-db=C:/code/HEAD/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Wno-error=inline " --constraint "binary == 0.8.5.1" --constraint "text == 1.2.3.0" --constraint "transformers == 0.5.4.0" --constraint "mtl == 2.2.2" --constraint "parsec == 3.1.12" --constraint "Cabal == 2.0.0.2" --constraint "hpc == 0.6.0.3" --constraint "ghc-boot-th == 8.3" --constraint "ghc-boot == 8.3" --constraint "template-haskell == 2.13.0.0" --constraint "ghci == 8.3" --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe" --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe" --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe" --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex" --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy" ...etc etc I'm stumped. Simon

3 6

RE: Hadrian
by Andrey Mokhov 20 Oct '17

20 Oct '17

Hi Moritz and Herbert, Thank you for detailed comments! We clearly need to carefully think through our options for merging Hadrian. Can I invite you both and everyone else to continue the discussion in https://github.com/snowleopard/hadrian/issues/440? Long email threads tend to become hard to read/follow and get lost. In my view, the two most important requirements in the long term are: 1) Preserving the commit/issue/pull-request history. A GHC developer fighting a strange build failure should be able to find a relevant discussion not only now but in 5 years from now. This may be solved via documentation, i.e. gradually moving all discussions from GitHub to docs/comments. That's a lot of hard work. 2) Making it convenient for GHC developers to work on Hadrian. To me, git submodules are not convenient at all, but maybe there is just no other option given the requirement (1). Is git subtree a solution? Cheers, Andrey

2 1

Re: Determine instance method from class method callsite
by Tillmann Vogt 20 Oct '17

20 Oct '17

I have the same problem with a compiler plugin that I am writing. In GHC Core I need to get from a dict-fun identifier (e.g. $fMyClassDouble to the type class instance bindr (starting with $c). lookupInstEnv from the InstEnv module seemed to do it, but it seems to look up the matching key from a set of instEnv keys and not anything that contains the instance bindr. Not sure. Where is the dictionary lookup that gives me the bindr? What I did so far: evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var -> CoreM NodeType evalExpr dflags guts (Var iD) v = do hsc_env <- getHscEnv eps <- liftIO (hscEPS hsc_env) let instEnvs = InstEnvs (eps_inst_env eps) (mg_inst_env guts) (mkModuleSet (dep_orphs (mg_deps guts))) let ty = tyConAppTyCon_maybe (idType iD) let cl = fromJust (tyConClass_maybe (fromJust ty)) let tys = snd (splitTyConApp (idType iD)) let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl tys | otherwise = ([],[],[]) let inst = map (nameStableString . varName . is_dfun . fst) matches liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))

2 1

RE: Hadrian
by Andrey Mokhov 20 Oct '17

20 Oct '17

Hi Ben, > Well, the GitHub repo will still exist. Is that enough? Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file: -- Objdump is only required on OpenBSD and AIX, as mentioned in #211. The reader might confuse this with GHC ticket #211, so I guess this should be replaced with a full link https://github.com/snowleopard/hadrian/issues/211. There may be other potential pitfalls, but hopefully nothing difficult to handle. I've created an issue to discuss and prepare for the merge: https://github.com/snowleopard/hadrian/issues/440. Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 19 October 2017 21:50 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Boespflug, Mathieu <m(a)tweag.io> Cc: Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io>; ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Thanks Ben, > > Just to clarify: By history I mean not just commits, but GitHub issues > and PRs as well -- together they contain a lot of valuable interlinked > information for GHC/Hadrian developers. > Well, the GitHub repo will still exist. Is that enough? Cheers, - Ben

3 3

RE: Hadrian
by Andrey Mokhov 19 Oct '17

19 Oct '17

Thanks Ben, Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers. > That is pretty much precisely the use-case which > git subtree was designed to address. This will allow us to have Hadrian, > with history, in the GHC tree and you can continue to develop it on > GitHub until things have stabilized. Sounds great. I haven't used git subtrees before, so I'll need to do some reading, but if everyone is happy with merging Hadrian as is, I can prepare a patch over the weekend! Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 19 October 2017 20:50 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Boespflug, Mathieu <m(a)tweag.io> Cc: Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io>; Moritz Angermann <moritz.angermann(a)gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben

2 1

RE: Hadrian
by Ben Gamari 19 Oct '17

19 Oct '17

Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben

1 0