- ghc-devs - Haskell.org

Re: Validating with Haddock
by Mateusz Kowalczyk 07 Jan '14

07 Jan '14

On 07/01/14 13:57, Simon Hengel wrote: > Hey! > Sorry for not being of much help with this right now. Regarding Haddock releases I think we updated the version used for Hackage independently of ghc before. Cheers. > Oh, if that's the case then I no longer feel that it's urgent that we get it into 7.8 considering Hackage is where the bulk of the docs are. -- Mateusz K.

1 0

Test suite regressions
by Joachim Breitner 06 Jan '14

06 Jan '14

Hi, travis-ci reports test suite failures. Unfortunately, the builds still sometimes timeout, so I cannot pin-point the precise change, but someone pushing today broke Unexpected failures: ghci/scripts T8639 [bad stdout] (ghci) polykinds T7594 [stderr mismatch] (normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/16345412/log.txt If you pushed today, please check if you might have broken them. And please validate your changes before pushing! (I have some scripts that make clean validating mostly hassle-free, based on a dedicated build host where I push to "validate/some-name", and after lunch I come back and see if the branch was renamed to "validated/some-name" or "broken/some-name" – I can share them if you are interested. Although I believe that we would benefit from a central, official solution.) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 1

Re: RE: Starting GHC development.
by Kyle Van Berendonck 06 Jan '14

06 Jan '14

The build/test system could be scaring away potential developers too. Not to complain or anything, but I used to try building GHC (form scratch) every 2 months or so and It would (usually) completely fail to build on Windows and OSX, and when it does, there would be some problem with the makefile where it either wouldn't rebuild properly and required a dist-clean or it wouldn't handle anything above -j1 properly. I'm (hoping) that these issues have been resolved by now. The test suite is also really scary. Regards.

1 0

Interface loading and dynamic linking
by Ben Gamari 04 Jan '14

04 Jan '14

In trying to test my LLVM-dynamic linking changes, I've encountered some builds which fail with, Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") during `make install`. The failing command is `ghc-stage2`, invoked by `ghc-cabal`, ../../inplace/bin/ghc-stage2 '-B/opt/exp/ghc/root-ghc-7.8-dyn/lib/ghc-7.7.20131221' '--abi-hash' '-fbuilding-cabal-package' '-O' '-outputdir' 'dist-install/build' '-odir' 'dist-install/build' '-hidir' 'dist-install/build' '-stubdir' 'dist-install/build' '-i' '-idist-install/build' '-i.' '-idist-install/build/autogen' '-Idist-install/build/autogen' '-Idist-install/build' '-optP-include' '-optPdist-install/build/autogen/cabal_macros.h' '-package-name' 'ghc-prim-0.3.1.0' '-hide-all-packages' '-no-user-package-db' '-package-id' 'builtin_rts' '-XHaskell2010' 'GHC.CString' 'GHC.Classes' 'GHC.Debug' 'GHC.IntWord64' 'GHC.Magic' 'GHC.PrimopWrappers' 'GHC.Tuple' 'GHC.Types' 'GHC.Prim' '-package-name' 'ghc-prim' The build is on an x86_64 box with `build.mk` containing, GhcDebugged = YES DYNAMIC_BY_DEFAULT = YES # Roughly BuildFlavour=quick-llvm without disabling dynamic linking SRC_HC_OPTS = -H64m -O0 -fllvm # -keep-llvm-files GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO I've spent the morning tracing through the interface loading code and have finally met an impasse. As far as I can tell, the relevant subset of the call graph is, LoadIface.lhs: loadInterface LoadIface.lhs : findAndReadIface Finder.hs: findExactModule Finder.hs: findHomeModule Finder.hs: homeSearchCache Finder.hs: findHomeModule findAndReadIface(read_file) findAndReadIface(checkBuildDynamicToo) whenGeneratingDynamicToo TcRnMonad.hs: withDoDynamicToo DynFlags.hs: dynamicTooMkDynamicDynFlags findAndReadIface(read_file) where findAndReadIFace(read_file) LoadIface.lhs : readIface BinIface.hs : readBinIface Up until `checkBuildDynamicToo` the dynflags have, ways dflags == [WayDyn] buildTag dflags == "dyn" hiSuf dflags == "hi" dynHiSuf dflags == "dyn_hi" Given this, it's perhaps unsurprising that `readBinIface` gets quite confused when it attempts to read `dist-install/build/GHC/CString.hi` to find that it was compiled with a null tag, not `dyn` as expected. If I add `-static` to the command line the build succeeds. However, adding `-dynamic` or `-dynamic-too` or omitting all of the above (due to `DYNAMIC_BY_DEFAULT`) all fail. It seems that `findAndReadIface` attempts to account for `-dynamic-too` but I don't see how the approach should work: it tries to first load the static interface file (but with `ways==[WayDyn]`) then tries again to load the interface using `DynFlags` and .hi file name constructed for the dynamic case. I can't see how this would ever work as `readBinIface` will expect to see a dynamic interface file due to the DynFlags' ways. It's also unclear how the `-dynamic` case (not `-dynamic-too`) is handled under this scheme. I would have thought that running with `-dynamic` would cause `hiSuf == dynHiSuf` but I can't find any code to suggest this is the case. Could someone offer some insight into how interface loading, `-dynamic`, and `-dynamic-too` are supposed to interact? Thanks, - Ben

4 9

Normal for make install to (re?)build libraries with stage1 compiler?
by Aaron Friel 04 Jan '14

04 Jan '14

Still working on getting my own development environment configured, I am seeing make install perform a lot of rebuilds of libraries: > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -c libraries/base/./GHC/IO/Encoding/Types.hs -o libraries/base/dist-install/build/GHC/IO/Encoding/Types.o However, GHC has already been built to stage 2. Why is GHC inplace/bin/stage1 being invoked here - and hasn’t this library already been built by make?

2 1

ticket for adding ARM backend to NCG?
by Corey O'Connor 04 Jan '14

04 Jan '14

Is there an existing ticket or wiki page describing the work required for adding an ARM backend to the NCG? I tried the following search with no luck: https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&statu… -Corey O'Connor coreyoconnor(a)gmail.com http://corebotllc.com/

9 13

GHC Api
by Simon Peyton-Jones 04 Jan '14

04 Jan '14

Simon and othere Happy new year! When debugging Trac #8628 I wrote the following: main = do [libdir] <- getArgs ok <- runGhc (Just libdir) $ do dflags <- getSessionDynFlags -- (1) setSessionDynFlags dflags liftIO (setUnsafeGlobalDynFlags dflags) -- (2) setContext [IIDecl (simpleImportDecl pRELUDE_NAME)] -- (3) runDecls "data X = Y Int" runStmt "print True" -- (4) return () There are several odd things here 1. Why do I have to do this "getSessionDynFlags/setSessionDynFlags" thing. Seems bizarre. I just copied it from some other tests in ghc-api/. Is it necessary? If not, can we remove it from all tests? 2. Initially I didn't have that setUnsafeGlobalDynFlags call. But then I got T8628.exe: T8628.exe: panic! (the 'impossible' happened) (GHC version 7.7.20131228 for i386-unknown-mingw32): v_unsafeGlobalDynFlags: not initialised which is a particularly unhelpful message. It arose because I was using a GHC built with assertions on, and a warnPprTrace triggered. Since this could happen to anyone, would it make sense to make this part of runGhc and setSessionDynFlags? 3. Initially I didn't have that setContext call, and got a complaint that "Int is not in scope". I was expecting the Prelude to be implicitly in scope. But I'm not sure where to fix that. Possibly part of the setup in runGhc? 4. The runStmt should print something somewhere, but it doesn't. Why not? What do you think? Simon

3 6

Re: [commit: packages/base] master: Add functions to compare Nat and Symbol types for equality. (c5c8c4d)
by Gabor Greif 04 Jan '14

04 Jan '14

Iavor, this is great! Just out of curiosity, you import TestEquality but never reference it. Is this an oversight, should I nuke it? Cheers, Gabor On 1/4/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/c5c8c4dfbdc8493bcfaa804751eff2a9a… > >>--------------------------------------------------------------- > > commit c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a > Author: Iavor S. Diatchki <diatchki(a)galois.com> > Date: Fri Jan 3 15:11:34 2014 -0800 > > Add functions to compare Nat and Symbol types for equality. > > >>--------------------------------------------------------------- > > c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a > GHC/TypeLits.hs | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs > index f3ba70e..129beb3 100644 > --- a/GHC/TypeLits.hs > +++ b/GHC/TypeLits.hs > @@ -26,6 +26,8 @@ module GHC.TypeLits > , KnownSymbol, symbolVal > , SomeNat(..), SomeSymbol(..) > , someNatVal, someSymbolVal > + , sameNat, sameSymbol > + > > -- * Functions on type nats > , type (<=), type (<=?), type (+), type (*), type (^), type (-) > @@ -40,7 +42,8 @@ import GHC.Read(Read(..)) > import GHC.Prim(magicDict) > import Data.Maybe(Maybe(..)) > import Data.Proxy(Proxy(..)) > -import Data.Type.Equality(type (==)) > +import Data.Type.Equality(type (==), TestEquality(..), (:~:)(Refl)) > +import Unsafe.Coerce(unsafeCoerce) > > -- | (Kind) This is the kind of type-level natural numbers. > data Nat > @@ -167,6 +170,23 @@ type family (m :: Nat) ^ (n :: Nat) :: Nat > type family (m :: Nat) - (n :: Nat) :: Nat > > > +-------------------------------------------------------------------------------- > + > +-- | We either get evidence that this function was instantiated with the > +-- same type-level numbers, or 'Nothing'. > +sameNat :: (KnownNat a, KnownNat b) => > + Proxy a -> Proxy b -> Maybe (a :~: b) > +sameNat x y > + | natVal x == natVal y = Just (unsafeCoerce Refl) > + | otherwise = Nothing > + > +-- | We either get evidence that this function was instantiated with the > +-- same type-level symbols, or 'Nothing'. > +sameSymbol :: (KnownSymbol a, KnownSymbol b) => > + Proxy a -> Proxy b -> Maybe (a :~: b) > +sameSymbol x y > + | symbolVal x == symbolVal y = Just (unsafeCoerce Refl) > + | otherwise = Nothing > > -------------------------------------------------------------------------------- > -- PRIVATE: > @@ -187,3 +207,4 @@ withSSymbol :: (KnownSymbol a => Proxy a -> b) > -> SSymbol a -> Proxy a -> b > withSSymbol f x y = magicDict (WrapS f) x y > > + > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

Re: Idea for improving communication between devs and potential devs
by Howard B. Golden 03 Jan '14

03 Jan '14

Chris, Thanks for the pointer to HWN. I wasn't aware of it before. I can certainly send things to the author which may be of interest to readers. In addition I like incorporating the updates into the GHC Devs wiki to make it easier to find them that way. We each have our preferred way of keeping up-to-date. Howard

1 0

Re: Idea for improving communication between devs and potential devs
by Chris Heller 03 Jan '14

03 Jan '14

I think a weekly summary like what LWN provides would be very valuable. Perhaps there is an opportunity to piggy-back this on the work of the Haskell Weekly News project ( http://contemplatecode.blogspot.com/search/label/HWN) -Chris

1 0