- Glasgow-haskell-users

RTS option -A affecting cpu-core usage?
by Daniel Trstenjak 08 Oct '13

08 Oct '13

Hi all, I played around with a parallel algorithm and tried to get the GC time down by specifying the RTS option '-A'. But if I'm specifying '-A' than also the usage of the cpu-cores seems to change. Without '-A' I'm getting a total cpu-core usage of '4.44s', with '-A' I'm getting only '1.67s'. Any ideas? Greetings, Daniel Without '-A': ------------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 XMonad.Util.XUtils 980,770,296 bytes allocated in the heap 552,122,168 bytes copied during GC 163,683,152 bytes maximum residency (11 sample(s)) 4,369,800 bytes maximum slop 280 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1690 colls, 1690 par 2.45s 0.66s 0.0004s 0.0024s Gen 1 11 colls, 10 par 0.98s 0.26s 0.0239s 0.1022s Parallel GC work balance: 18.06% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 1025 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 0.99s ( 0.83s elapsed) GC time 3.43s ( 0.93s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 4.44s ( 1.78s elapsed) Alloc rate 995,571,064 bytes per MUT second Productivity 22.7% of total user, 56.5% of total elapsed gc_alloc_block_sync: 53552 whitehole_spin: 0 gen[0].sync: 75 gen[1].sync: 23678 With '-A': ---------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 -A500m XMonad.Util.XUtils 979,761,872 bytes allocated in the heap 94,043,424 bytes copied during GC 118,609,784 bytes maximum residency (2 sample(s)) 2,844,808 bytes maximum slop 2196 MB total memory in use (0 MB lost due to fragmentati Tot time (elapsed) Avg pause Ma Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s Gen 1 2 colls, 1 par 0.47s 0.18s 0.0878s Parallel GC work balance: 57.02% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (616 converted, 0 overflowed, 0 dud, 0 GC'd, 409 fizzl INIT time 0.02s ( 0.02s elapsed) MUT time 1.16s ( 1.16s elapsed) GC time 0.47s ( 0.18s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 1.67s ( 1.38s elapsed) Alloc rate 844,914,346 bytes per MUT second Productivity 70.8% of total user, 85.9% of total elapsed gc_alloc_block_sync: 33458 whitehole_spin: 0 gen[0].sync: 5372 gen[1].sync: 0

1 1

Desugaring do-notation to Applicative
by Simon Marlow 05 Oct '13

05 Oct '13

Following a couple of discussions at ICFP I've put together a proposal for desugaring do-notation to Applicative: http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo I plan to implement this following the addition of Applicative as a superclass of Monad, which is due to take place shortly after the 7.8 branch is cut. Please discuss here, and I'll update the wiki page as necessary. Cheers, Simon

13 14

carriage returns on Windows from quasi-quotes
by Greg Weber 05 Oct '13

05 Oct '13

A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns?

2 2

Trying to compile ghc HEAD on xubuntu 13.04-x64
by Nathan Hüsken 04 Oct '13

04 Oct '13

Hey, because I have touble with ghci and packages with FFI, it was suggested to me to compile and use ghc HEAD. I am on xubuntu 13.04 64bit and try to do a perf build. It fails with: compiler/ghc.mk:478: warning: ignoring old commands for target `compiler/stage2/build/libHSghc-7.7.20131004-ghc7.7.20131004.so' "/home/ls/src/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-O --optghc=-H64m --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /366) in 'GHC.PrimopWrappers' 72% (813 /1132) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20131004 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make: *** [all] Error 2 Suggestions? Thanks! Nathan

3 2

RE: Desugaring do-notation to Applicative
by Neil Sculthorpe 02 Oct '13

02 Oct '13

While I really like applicative notation, sometimes naming intermediate results can make code a lot more readable. So I think supporting applicative do-notation would be beneficial. Neil On 02/10/13 07:00, p.k.f.holzenspies wrote: > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Oct 2013 09:12:26 +0000 > From: <p.k.f.holzenspies(a)utwente.nl> > To: <iavor.diatchki(a)gmail.com>, <dag.odenhall(a)gmail.com> > Cc: marlowsd(a)gmail.com, glasgow-haskell-users(a)haskell.org, > simonpj(a)microsoft.com > Subject: RE: Desugaring do-notation to Applicative > Message-ID: > <E7F535B24A47D747A07D46C0AA82D43D0AB17531(a)EXMBX21.ad.utwente.nl> > Content-Type: text/plain; charset="utf-8" > > I thought the whole point of Applicative (at least, reading Connor?s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation. > > That being said, I?m all for something that will promote the use of the name ?pure? over ?return?. > > +1 for the Opt-In > > Ph. > >

1 0

openindiana binaries
by asyropoulos＠aol.com 30 Sep '13

30 Sep '13

Hello, This weekend I tried to compile ghc-7.6.3 on OpenIndiana using an older version that was posted at http://www.haskell.org/ghc/download_ghc_7_0_3 I have used this version to compile install pandoc and pandoc compiled just fine and it works! However, I have noticed that libffi.so.6 should not be installed in a non standard folder, and I have no idea if this is a problem of OpenIndiana or Solaris more generally. Now, I think it would be nice to add this version to the download page, do you know whom I have to contact for the relevant details? Regards, A.S. -- Apostolos Syropoulos Xanthi, Greece

2 2

Executables using GHC API require dynamic linking in GHC 7.7
by Christiaan Baaij 28 Sep '13

28 Sep '13

Dear all, It seems that executables that use the GHC API require to be dynamically linked on GHC 7.7. At least in the case that an GHC API function has to perform linking. Statically linked executable SEGFAULT when a GHC API function tries to do linking. I build 'haddock' from source by doing a 'cabal install' in the 'utils/haddock' directory of my ghc build tree. Here is the output of my statically linked haddock when I run it on one of my libraries: Haddock coverage: Warning: main:CLaSH.Util: Could not find documentation for exported module: X Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses 95% ( 18 / 19) in 'CLaSH.Util' 100% ( 8 / 8) in 'CLaSH.Core.TyCon' 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' 100% ( 5 / 5) in 'CLaSH.Core.DataCon' 100% ( 3 / 3) in 'CLaSH.Core.Literal' 100% ( 5 / 5) in 'CLaSH.Core.Var' Bus error: 10 <-- SEGFAULT Here is the output of my dynamically linked haddock when I run it on one of my libraries: Haddock coverage: Warning: main:CLaSH.Util: Could not find documentation for exported module: X Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses 95% ( 18 / 19) in 'CLaSH.Util' 100% ( 8 / 8) in 'CLaSH.Core.TyCon' 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' 100% ( 5 / 5) in 'CLaSH.Core.DataCon' 100% ( 3 / 3) in 'CLaSH.Core.Literal' 100% ( 5 / 5) in 'CLaSH.Core.Var' 100% ( 5 / 5) in 'CLaSH.Core.Term' 100% ( 8 / 8) in 'CLaSH.Core.Subst' 100% ( 24 / 24) in 'CLaSH.Core.Type' <… lots of warnings about missing link destination … > ~/Documents/devel/clash/src (master *)$ I believe that the use of TH in the CLaSH.Core.Var file triggers the segfault in the statically linked version. I'm trying to create a smaller test case than running haddock on my library, but have been unsuccessful so far. That is why I haven't posted a bug report on the bug tracker yet. If somebody thinks I should, then please say so :-) My platform is: OS: OS X 10.8.5 XCode: X-Code CL-tools 4.6.2 GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546) Build.mk: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO I hope somebody can test this on linux with dynamic linking. As this bug affects haddock, I think it is quite important that somebody with more knowledge of dynamic linking looks into this. Regards, Christiaan

2 1

desugarModule
by Kazu Yamamoto 19 Sep '13

19 Sep '13

Hi, The document of GHC API says that "desugarModule" displays warnings of pattern matching even if HscNothing is specified: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:HscTar… Unfortunately, I cannot get warnings of pattern matching. To demonstrate this, I attached two files: - Main.hs -- using "desugarModule" - B.hs -- a target file: top level signature is missing, pattern is imcompleted When I run "Main.hs" with: % runghc -- -package --ghc-arg=ghc -Wall Main I only got: B.hs:6:1: Warning: Top-level binding with no type signature: main :: IO () Does anyone know how to display warnings of pattern matching with HscNothing? --Kazu <Main> -- runghc -- -package --ghc-arg=ghc A module Main where import GHC import GHC.Paths (libdir) import DynFlags main :: IO () main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ runGhc (Just libdir) $ getWarings "B.hs" "B" getWarings :: String -> String -> Ghc () getWarings targetFile targetModule = do dflags <- getSessionDynFlags let dflags' = dflags { ghcLink = NoLink , hscTarget = HscNothing } dflags'' = foldl wopt_set dflags' [Opt_WarnMissingSigs,Opt_WarnIncompletePatterns] _ <- setSessionDynFlags dflags'' target <- guessTarget targetFile Nothing setTargets [target] _ <- load LoadAllTargets modSum <- getModSummary $ mkModuleName targetModule p <- parseModule modSum t <- typecheckModule p _ <- desugarModule t return () </Main> <B> module B where myHead :: [Int] -> Int myHead (x:_) = x main = do print $ myHead [1,2,3] </B>

1 0

7.8 Release Update
by Austin Seipp 16 Sep '13

16 Sep '13

Friends, After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow. Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing. Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch. However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything: * Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here? * Trevor and Iavor are also working on kinds without data. Any word here? * Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great. * Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so. * Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great. * Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week. * I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams. IMO, most of these look to be in good shape, I think. If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week. In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular. Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it. -- Regards, Austin - PGP: 4096R/0x91384671

11 35

RE: Question about correct GHC-API use for type checking (or zonking, or tidying)
by p.k.f.holzenspies＠utwente.nl 11 Sep '13

11 Sep '13

Well, my tcLocalBinds seems to have a different type then yours (this is from my copy of 7.6.3 and it's the same in the HEAD that I just synced): tcLocalBinds :: HsLocalBinds Name -> TcM thing -> TcM (HsLocalBinds TcId, thing) If I want to get a GblEnv out, I can use getGblEnv, but doing this: mkId :: Maybe FreeVars -> LHsExpr Name -> Name -> TcM Id mkId fvs expr@(L l _) nm = do ((binds', gbl_env),lie) <- captureConstraints $ tcLocalBinds binds getGblEnv setGblEnv gbl_env (tcLookupId nm) where binds = HsValBinds $ ValBindsOut [(NonRecursive, unitBag fixbnd)] [] the_bind = mkTopFunBind (L l nm) [mkMatch [] expr emptyLocalBinds] fixbnd = L l $ maybe the_bind (\vs -> the_bind { bind_fvs = vs }) fvs fails on the tcLookupId with a GHC internal error complaining that my name is "not in scope during type checking, but it passed the renamer." Ph. From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] Sent: dinsdag 10 september 2013 14:19 To: Holzenspies, P.K.F. (EWI) Cc: glasgow-haskell-users(a)haskell.org Subject: RE: Question about correct GHC-API use for type checking (or zonking, or tidying) What goes wrong if you follow my suggestion below? tcLocalBinds takes a set of bindings, such as x=e and returns a GblEnv whose type envt is extended with a binding for x with its generalised type. This type wil indeed be closed, unless the current environment (in which tcLocalBinds runs) has bindings with open types. Which in your case it probably doesn't. I feel that I am not being helpful but I'm not sure how to help more. S From: "Philip K.F. Hölzenspies" [mailto:p.k.f.holzenspies@utwente.nl] Sent: 04 September 2013 21:25 To: Simon Peyton-Jones Cc: glasgow-haskell-users(a)haskell.org<mailto:glasgow-haskell-users@haskell.org> Subject: Re: Question about correct GHC-API use for type checking (or zonking, or tidying) Ah, this is good to know. What I really would like is a function: mkId :: Name -> LHsExpr Name -> TcM Id where that Id is something I can store in my own monad (IA). The meaning of this, is indeed "let <name> = <expression>" as a top-level binding. The behaviour should actually be the same as that statement at the ghci-prompt. My IA monad implements liftTcM as something that invokes a TcM-monad, i.e. liftTcM :: TcM b -> IA b liftTcM thing_inside = do hsc_env <- getSession stored_ids <- getStoredIds :: IA [Id] -- this is the list of all Ids made through mkId mentioned above ioMsgMaybe . initTcPrintErrors hsc_env iNTERACTIVE $ setInteractiveContext hsc_env (hsc_IC hsc_env) $ tcExtendGlobalValEnv stored_ids $ -- or tcExtendIdEnv?? thing_inside In the example you give below, I'm curious which "thing_inside" you give to tcLocalBinds to get you the correct global environment. Also, if I do what you suggest, i.e. poly_id <- setGblEnv gbl_env (tcLookupId the_id_name) is that poly_id "self contained," in the sense that I can put it in a new instantiation as shown above? Regards, Philip [cid:image001.jpg@01CEAEDB.407DA510] Simon Peyton-Jones<mailto:simonpj@microsoft.com> September 4, 2013 6:00 PM The id you are getting is a monomorphic id, with a type like a->a, not the polymorphic forall a. a->a. You don't want to go round arbitrarily creating a new Id with the same unique but a different type. I have no idea what would happen then. It's hard for me to understand just what you code is trying to do. I think you are making bindig it = <some expr> and then you want the type of "it". Maybe something like (binds', gbl_env) <- tcLocalBinds (..your bindin..) poly_id <- setGblEnv gbl_env (tcLooupId the_id_name) But I'm not totally sure. S

1 0