- ghc-devs - Haskell.org

(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%2FNkouOHNgZ69ag(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

Adding atomic primops
by Johan Tibell 09 Jun '14

09 Jun '14

Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan

7 22

[PATCH] Fix -unawareness of large-addresses on mingw (#8520)
by transfuturist 08 Jun '14

08 Jun '14

--- compiler/main/SysTools.lhs | 1 + 1 file changed, 1 insertion(+) diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index dc9642d..1cf1155 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do [ -- Reduce ld memory usage "-Wl,--hash-size=31" , "-Wl,--reduce-memory-overheads" + , "-Wl,--large-address-aware" --Trac #8520 -- Increase default stack, see -- Note [Windows stack usage] , "-Xlinker", "--stack=0x800000,0x800000" ] -- 1.8.4.msysgit.0

3 4

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

08 Jun '14

Hi, Am Sonntag, den 08.06.2014, 07:55 +0300 schrieb Michael Snoyman: > > Actually, GHC HEAD isn't the problem I'm running into right now. I'm > already testing that[1] using Herbert's Ubuntu PPA[2] Ah, cool! > I'm specifically looking for builds off of the 7.8 branch so I can > start testing point releases. Then I guess the easiest would be if Herbert would add that to his PPA. > [2] And in case anyone's curious, restrictive upper bounds on > transformers and template-haskell are preventing a build right now. Hmm, it would be nice if cabal had a “best effort” mode where when some of the requested packages cannot be built it at least builds the rest. Also, isn’t there a new flag to cabal to selectively ignore upper bounds? (I can’t find the documentation for the latest cabal-install online right now.) 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

2 1