June 2014 - ghc-devs - Haskell.org

Re: Windows breakage (+patch)
by Sergei Trofimovich 11 Jun '14

11 Jun '14

On Wed, 11 Jun 2014 21:35:57 +0300 Sergei Trofimovich <slyfox(a)gentoo.org> wrote: > On Wed, 11 Jun 2014 08:18:30 +0000 > Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > > Stefan, Guys > > This commit breaks the Windows build (ie my laptop) > > > > commit 9fd507e5758f4141ac2619f0db57136bcab035c6 > > > > Author: Sergei Trofimovich <slyfox(a)gentoo.org> > > > > Date: Fri May 23 23:58:06 2014 +0300 > > > > > > > > Raise exceptions when blocked in bad FDs (fixes Trac #4934) > > The breakage is this: > > > > C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' > > The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS > > > > getStablePtr((StgPtr)blockedOnBadFD_closure); > > I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. > > Can someone do this, please? > > Oh, I've missed the fact GHC.Event.Thread in a non-windows thing. > The whole patch was for posix-only platform, but i tried to export > that exception for all platforms. > > CCed Simon M. > > There is 2 routes: > a) move an exception a common module to all platforms. > For example to Foreign.C.Error (I've started to prepare a patch) To avoid import loops and make things clear I've moved it to GHC.Exception.RTS (other from-rts exceptions can be pushded there as well) Patch is in attach. Please review. Thank you! -- Sergei

1 0

Re: [commit: ghc] master: Update mod73 test output (1178fa4)
by Richard Eisenberg 11 Jun '14

11 Jun '14

This test case is failing on my machine, too. Is it perhaps possible to sort the output to avoid these wibbles? I looked at the code and it's not immediately obvious to me the best place to do this... Thanks, Richard On Jun 6, 2014, at 10:09 AM, git(a)ghc.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/1178fa4ada1ac054976f3abb2e303ad42… > >> --------------------------------------------------------------- > > commit 1178fa4ada1ac054976f3abb2e303ad42653e303 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Fri Jun 6 15:03:36 2014 +0200 > > Update mod73 test output > > to what I observe on travis and on my validate machine, even though my > local tree produces the previous output. > > >> --------------------------------------------------------------- > > 1178fa4ada1ac054976f3abb2e303ad42653e303 > testsuite/tests/module/mod73.stderr | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/testsuite/tests/module/mod73.stderr b/testsuite/tests/module/mod73.stderr > index d19a032..576b0e3 100644 > --- a/testsuite/tests/module/mod73.stderr > +++ b/testsuite/tests/module/mod73.stderr > @@ -2,6 +2,6 @@ > mod73.hs:3:7: > Not in scope: ‘Prelude.g’ > Perhaps you meant one of these: > - data constructor ‘Prelude.GT’ (imported from Prelude), > + data constructor ‘Prelude.LT’ (imported from Prelude), > data constructor ‘Prelude.EQ’ (imported from Prelude), > - data constructor ‘Prelude.LT’ (imported from Prelude) > + data constructor ‘Prelude.GT’ (imported from Prelude) > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Hashes for download files
by Yitzchak Gale 11 Jun '14

11 Jun '14

Perhaps it would be a good idea to post hashes on the download site for each downloadable file, to make it easier to verify that you have the genuine article. Thanks, Yitz

1 0

(drop)CommonPrefix: ccs call implementation
by Maarten Faddegon 11 Jun '14

11 Jun '14

Dear list, I am reading up on cost centre stacks. Simon Marlow's "solving an old problem"-slides is the more recent resource I could find. On slide 43 he describes a call function implemented as: > call Sapp Slam = foldr push Spre Slam’ > where (Spre, Sapp’, Slam’) = commonPrefix Sapp Slam However in rts/profiling.c the following is written: > Set CCCS when entering a function. > > The algorithm is as follows. > > ccs ++> ccsfn = ccs ++ dropCommonPrefix ccs ccsfn > > where > > dropCommonPrefix A B > -- returns the suffix of B after removing any prefix common > -- to both A and B. > > e.g. > > <a,b,c> ++> <> = <a,b,c> > <a,b,c> ++> <d> = <a,b,c,d> > <a,b,c> ++> <a,b> = <a,b,c> > <a,b> ++> <a,b,c> = <a,b,c> > <a,b,c> ++> <a,b,d> = <a,b,c,d> For the given examples Simon's proposal would result in different stacks: <>, <d>, <a,b>, <a,b,c> and <a,b,d>. Has the implementation changed since Simon Marlow gave his talk? If so, is there something I can read on the motivation behind this change? Or do I maybe misinterpret the slides? Thank you, Maarten Faddegon

3 3

Windows breakage
by Simon Peyton Jones 11 Jun '14

11 Jun '14

Stefan, Guys This commit breaks the Windows build (ie my laptop) commit 9fd507e5758f4141ac2619f0db57136bcab035c6 Author: Sergei Trofimovich <slyfox(a)gentoo.org> Date: Fri May 23 23:58:06 2014 +0300 Raise exceptions when blocked in bad FDs (fixes Trac #4934) The breakage is this: C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS getStablePtr((StgPtr)blockedOnBadFD_closure); I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. Can someone do this, please? Thanks Simon

1 0

Re: GHC/cabal release procedures, and Stackage
by Joachim Breitner 10 Jun '14

10 Jun '14

Hi, Am Sonntag, den 08.06.2014, 21:25 +0300 schrieb Michael Snoyman: > That's great news, thanks! I'll try to get a test going with that. Another benefit of this would be that it is more likely that $ cabal install criterion --with-compiler=.../ghc/inplace/bin/ghc-stage2 works, which would be very handy when developing on GHC head (currently it fails to compile attoparsec, as reported by Gabor). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

SV: GHC MinGW distribution
by Niklas Larsson 10 Jun '14

10 Jun '14

I think this is a great idea, I was thinking of creating a ticket for it after 7.8.3 was out of the way. In my case the reason is C++11 support, LLVM has 4.7 as the minimum version now. Just having a script in git and downloading the tarballs sounds very sensible. Speaking of LLVM, how about making it (optionally?) download an llvm tarball too? Niklas ----- Ursprungligt meddelande ----- Från: "Robin KAY" <komadori(a)gekkou.co.uk> Skickat: ‎2014-‎06-‎10 01:46 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: GHC MinGW distribution Dear All, I wanted to enquire about the prospects for updating the version of MinGW which ships with the Windows binary distribution of GHC. The version included as of 7.8.2 is now several years old and in some cases I've found that it's incompatible with the libraries produced by newer versions of MinGW (as to be expected, per my understanding). Specifically, my HsQML binding for Qt can't be used with the libraries from the official Windows binary distribution of Qt 5 because the resulting executables crash on start-up with runtime incompatibilities. I'm in the process of trying to build out-of-the-box compatible Qt binaries against GHC's MinGW, but Qt's stated minimum requirements on the tool-chain version aren't encouraging. The only way I currently have of making this work is for users to edit their GHC settings file to point GHC at a version of gcc.exe from a newer MinGW (such as the one which ships with Qt). The fact that this seems to work is encouraging, but it's still a bit of a difficult process to put people through. I know that Windows developers are in short supply, so I would like to offer what assistance I can in making this happen. There appear to be copies of MinGW stored in the GHC repository at http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use these automatically or are they just there for reference? Thanks, -- Robin KAY _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

ghc 7.8.2: Reachable modules from DynFlags out of date
by Peter Trommler 10 Jun '14

10 Jun '14

Hi, Preparing ghc for the upcoming Haskell Platform 2014.2 on openSUSE I came across the following issue on PowerPC 64 bit: > [ 6023s] inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" > [ 6025s] Reachable modules from DynFlags out of date > [ 6025s] Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) > [ 6025s] Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream > [ 6025s] make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 My build.mk contains the following: > GhcUnregisterised=YES > GhcWithNativeCodeGen=NO > GhcWithInterpreter=NO > SplitObjs=NO > SRC_HC_OPTS+= -optc-mminimal-toc -optc-fno-builtin > SRC_CC_OPTS+= -mminimal-toc -fno-builtin I need the last two lines to: 1. have the build get that far (something is overflowing the TOC on powerpc64) 2. to get rid of loads of gcc warnings about built-in mem* functions What do I need to do to „fix compiler/ghc.mk“ (see line 3 of my build log excerpt)? Thanks! Peter

1 0

Re: [commit: ghc] ghc-7.8: Release notes (32b4bf3)
by Herbert Valerio Riedel 10 Jun '14

10 Jun '14

On 2014-06-09 at 18:08:20 +0200, git-4Dsf34iY/NkouOHNgZ69ag(a)public.gmane.org wrote: [...] > + <listitem> > + <para> > + The libraries <literal>haskeline</literal>, > + <literal>xhtml</literal>, <literal>terminfo</literal>, > + <literal>transformers</literal>, and > + <literal>haskeline</literal> are now exported and > + registered in the package database. They previously > + shipped with GHC but were not registered, leading to > + errors where shared objects could be overwritten. (issue > + #8919). > + </para> > + </listitem> Just a minor nit-pick: Afaik, 'transformers' *was* properly exported & registered in 7.8.[12]. It just wasn't mentioned in the release notes for 7.8.[12] IIRC.

1 0

Failed to load interface for GHC.Integer.Type
by Joachim Breitner 10 Jun '14

10 Jun '14

Hi, since http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd65… travis is complaining: HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o Top level: Failed to load interface for â€˜GHC.Integer.Typeâ€™ There are files missing in the â€˜integer-gmpâ€™ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Does anyone have an idea what may be causing this? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 6