- Glasgow-haskell-users

semaphore functions in the wrong place during cross-build
by Tyler Pirtle 07 Mar '11

07 Mar '11

Hi, I'm not sure where the right place is to configure this. While linking hsunix + some others, the compiler assumes that -lrt is the appropriate library to find semaphore-related functions, but for the particular toolchain i'm building against, those functions are actually in -lpthread. Is there an easy way i can configure this? Thanks.

3 4

[igouy2@yahoo.com: fyi benchmarks game GHC 7.0.2]
by Don Stewart 04 Mar '11

04 Mar '11

----- Forwarded message from Isaac Gouy <igouy2(a)yahoo.com> ----- Date: Fri, 4 Mar 2011 09:11:16 -0800 (PST) From: Isaac Gouy <igouy2(a)yahoo.com> To: Don Stewart <dons(a)galois.com> Subject: fyi benchmarks game GHC 7.0.2 Hi A couple of the measurement differences to GHC 7.0.1 look strange, just letting you know. fannkuchredux,ghc,3 fasta,ghc,1 http://alioth.debian.org/scm/viewvc.php/shootout/website/websites/u64q/data… best wishes, Isaac ----- End forwarded message -----

1 0

problem running ghc-api code in ghci 7.0.x
by Daniel Gorín 03 Mar '11

03 Mar '11

Hi I have code using the ghc-api that could be run in interactive mode prior to version 7 but now makes ghci crash with a linker error. Everything works fine if compiled before running. I don't know if this is a known issue or if I'm just using the api in the wrong way, but I thought that I might ask. To illustrate the problem, consider this simple example: t.hs: > import qualified GHC > import qualified GHC.Paths > > main = GHC.runGhcT (Just GHC.Paths.libdir) $ do > -- begin initialize > df0 <- GHC.getSessionDynFlags > let df1 = df0{GHC.ghcMode = GHC.CompManager, > GHC.hscTarget = GHC.HscInterpreted, > GHC.ghcLink = GHC.LinkInMemory, > GHC.verbosity = 0} > _ <- GHC.setSessionDynFlags df1 > -- begin reset > GHC.setContext [] [] > GHC.setTargets [] > _ <- GHC.load GHC.LoadAllTargets > return () I then see: # ghci-6.12.1 -package ghc t.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. [...] Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( dint.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package ghc-paths-0.1.0.6 ... linking ... done. *Main> # ghci-7.0.1 -package ghc t.hs GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. [...] Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( dint.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package ghc-paths-0.1.0.8 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_ghczmprim_GHCziBool whilst processing object file /Library/Frameworks/GHC.framework/Versions/7.0.1-i386/usr/lib/ghc-7.0.1/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. # ghc-7.0.1 --make -package ghc t.hs [1 of 1] Compiling Main ( t.hs, t.o ) Linking t .. # ./t # (that is, no error) I'm using ghc for mac (intel 32 bits), downloaded in binary form from the ghc page. Thanks, Daniel

1 0

testing 7.02-candidate
by Serge D. Mechveliani 02 Mar '11

02 Mar '11

This is to add to my last letter. It is curious that this 7.02 candidate stucks at оverlapping instances only when compiling the test: T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' ... In earlier versions, if any of them stuck at оverlapping instances, the report was earlier, when compiling the DoCon library. ----------- Mechveliani

1 0

Faster Array#/MutableArray# copies
by Johan Tibell 01 Mar '11

01 Mar '11

Hi, Daniel Peebles has done a great job adding new primops for copying arrays (both Array# and MutableArray#). This gave me a nice speedup for my hash-array mapped trie (HAMT) data structure, which is now about as fast as Data.Map for inserts but about 5.5x faster for lookups. (It should also have a lower per key/value overhead.) However, for the HAMT is more than twice as slow for inserts compared to IntMap and copying arrays is still the bottleneck. C compilers, like gcc, go to great lengths making memcpy fast and I was thinking that we might be able to steal a trick or two from them. I'd like some feedback on these ideas: * Could we try to make the array primops inline? If so, would that mean that if e.g. the number of elements to copy is known at the (Haskell) call site it would also be known in C-- and we could get the benefits of knowing that? * Could we use built-in compiler rules to catch array copies of known length and replace them with e.g. unrolled loops? My particular use case involves copying small arrays (size: 1-32). Ideally this should be as fast as copying a tuple of the corresponding size but I'm pretty sure we're far off that goal. * Can we use SSE instructions? * Can we get the C memcpy code inlined into the C-- source (crazy, I know). If so we could perhaps benefit directly from optimizations in libc. Johan

7 12

SMP parallelism gains inferior than expected
by José Pedro Magalhães 01 Mar '11

01 Mar '11

Hi, I have a program that computes a matrix of Floats of m rows by n columns. Computing each Float is relatively expensive. Each line is completely independent of the others, so I thought I'd try some simple SMP parallelism on this code: myFun :: FilePath -> IO () myFun fp = do fs <- readDataDir fp let process f = readFile' f >>= parse printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) "" runDiff l = [ [ diff x y | y <- l ] | (x,i) <- zip l (map getId fs), myFilter i ] ps <- mapM process fs sequence_ [ printLine x | x <- runDiff ps *`using` parList rdeepseq* ] So, I'm using parList to evaluate the rows in parallel, and fully evaluating each row. Here are the timings on a Dual Quad Core AMD 2378 @2.4 GHz, ghc-6.12.3, parallel-2.2.0.1: -N time (ms) none 1m50 2 1m33 3 1m35 4 1m22 5 1m11 6 1m06 7 1m45 The increase at 7 is justified by the fact that there were two other processes running. I don't know how to justify the small increase at N3, though, but that doesn't matter too much. The problem is that I am not getting the gains I expected (halving at N2, a third at N3, etc.). Is this the best one can achieve with this implicit parallelism, or am I doing something wrong? In particular, is the way I'm printing the results at the end destroying potential parallel gains? Any insights on this are appreciated. Thanks, Pedro

2 2

ghc-pkg regression (or deliberate change)?
by Tyler Pirtle 01 Mar '11

01 Mar '11

Hi there, I'm using a system with an older version of GHC (6.8.3), and invoking ghc-pkg against a non-existing file in -f: $ haskell/ghc/v683/k8/lib/ghc-6.8.3/ghc-pkg.bin --global-conf haskell/ghc/v683/k8/lib/ghc-6.8.3/package.conf -f /tmp/nonexistent.Foo.package.conf register /tmp/Foo.package_spec ghc-pkg happily creates the file referenced with -f and fills it with these contents: [InstalledPackageInfo {package = PackageIdentifier {pkgName = "hsS-SFoo", pkgVersion = Version {versionBranch = [1,0], versionTags = []}}, license = AllRightsReserved, copyright = "", maintainer = "", author = "", stability = "", homepage = "", pkgUrl = "", description = "", category = "", exposed = False, exposedModules = [], hiddenModules = [], importDirs = [], libraryDirs = [], hsLibraries = [], extraLibraries = [], extraGHCiLibraries = [], includeDirs = [], includes = [], depends = [], hugsOptions = [], ccOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = [], haddockHTMLs = []} ] GHC 7.0.1 it appears does not do the same thing: $ haskell/ghc/v701/k8/lib/ghc-7.0.1/ghc-pkg --global-conf haskell/ghc/v701/k8/lib/ghc-7.0.1/package.conf.d -f /tmp/nonexistent.Foo.package_conf --force register /tmp/Foo.package_spec ghc-pkg: .../bin/hs/Foo.package_conf: openFile: does not exist (No such file or directory) (paths have been mangled by hand). ghc-pkg in 6.8.3 does what it does even without using --force. What am i missing in 7.0.1? Is this a bug or is this intentional? Thanks, Tyler

2 1

ANNOUNCE: GHC 7.0.2 Release Candidate 1
by Ian Lynagh 27 Feb '11

27 Feb '11

We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

10 17

weird behaviour of context resolution with FlexibleContexts and TypeFamilies
by Sittampalam, Ganesh 26 Feb '11

26 Feb '11

Hi, If I build the code below with -DVER=2, I get a complaint about PatchInspect (PrimOf p) being missing from the context of cleverNamedResolve. This doesn't happen with -DVER=1 or -DVER=3 I presume that type class resolution is operating slightly differently in the different cases, but it's quite confusing - in the original code joinPatches did something useful and I was trying to inline the known instance definition. I would have expected it to be consistent between all three cases, either requiring the context or not. Is it a bug, or just one of the risks one takes by using FlexibleContexts? I've tried this with GHC 6.12.3 and with 7.0.2RC2. Cheers, Ganesh {-# LANGUAGE CPP, TypeFamilies, FlexibleContexts #-} module Class ( cleverNamedResolve ) where data FL p = FL p class PatchInspect p where instance PatchInspect p => PatchInspect (FL p) where type family PrimOf p type instance PrimOf (FL p) = PrimOf p data WithName prim = WithName prim instance PatchInspect prim => PatchInspect (WithName prim) where class (PatchInspect (PrimOf p)) => Conflict p where resolveConflicts :: p -> PrimOf p instance Conflict p => Conflict (FL p) where resolveConflicts = undefined type family OnPrim p #if VER==1 class FromPrims p where instance FromPrims (FL p) where joinPatches :: FromPrims p => p -> p #else #if VER==2 joinPatches :: FL p -> FL p #else joinPatches :: p -> p #endif #endif joinPatches = id cleverNamedResolve :: (Conflict (OnPrim p) ,PrimOf (OnPrim p) ~ WithName (PrimOf p)) => FL (OnPrim p) -> WithName (PrimOf p) cleverNamedResolve = resolveConflicts . joinPatches =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

4 4

Cabal things
by Volker Wysk 23 Feb '11

23 Feb '11

Hello I'm new to Cabal, and I'm trying to Cabalize my library HsShellScript, with help by Howard Golden. I'm using the Simple Build Infrastructure. 1. I'm irritated by the fact, that calling the Cabal with "runhaskell configure; runhaskell build; runhaskell install" is _not_ sufficent in many cases. You need additional arguments for "runhaskell configure", and "runhaskell build" can't build everything, you need other actions in many cases. I need haddock, and it can't be specified in the .cabal file, or run by "runhaskell build". I'm about to include this Makefile: -----snip------ default :: build configure :: runhaskell Setup.lhs configure --ghc --prefix=/tmp build :: runhaskell Setup.lhs build runhaskell Setup.lhs haddock install :: runhaskell Setup.lhs install -----snip------ This would make the installation a matter of "make configure; make; make install". Is this the way it should be done? 2. I have some HTML pages of additional documentation, which need to be installed, and need to be included in the (sdist) generated distribution package. I have no clue how this should be done. Cheers, Volker

2 1