- Glasgow-haskell-users

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

Question about Haskell AST
by Jane Ren 22 Feb '11

22 Feb '11

Hi, I need to be able to take a piece of Haskell source code and get an simplified, typed, intermediate representation of the AST, which means I need to use compiler/coreSyn/CoreSyn.lhs So I'm first trying to get the desguaredModule of the source code with ... modSum <- getModSummary $ mkModuleName "..." p <- parseModule modSum t <- typecheckModule p d <- desugarModule t Now I'm really stuck on figuring out how to connect the variable d of type desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like App, Let, Case, etc. Also, is it correct to get the deguaredModule first? At least CoreSyn.lhs seems to suggest this. Any suggestions would be greatly apprecia

6 10

Recompile with -fPIC (was "building a patched ghc")
by José Pedro Magalhães 20 Feb '11

20 Feb '11

Hi all, I'm getting the same error as Alexy below in some 64bit linux system. What can I do? Adding -fPIC and also -dynamic does not seem to solve the problem. Also, this only happens with a perf build; devel1 works fine. Thanks, Pedro On Sat, Jun 26, 2010 at 05:56, braver <deliverable(a)gmail.com> wrote: > An attempt to build the trunk gets me this: > > /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64- > pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation > R_X86_64_PC32 against symbol `StgRun' can not be used when making a > shared object; recompile with -fPIC > > -- I use prefix portage on a CentOS box, admittedly a non-standard > setup. Its gcc is found first and it wants -fPIC... Should I just > add it to CFLAGS or what? > > -- Alexy > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 3

Behavior of the -H RTS option, possible doc/impl mismatch
by Akio Takano 18 Feb '11

18 Feb '11

Hi, I have questions regarding to the -H RTS option. I use GHC 7.0.1 on Linux x86-64. The User's Guide says: -Hsize [Default: 0] This option provides a “suggested heap size” for the garbage collector. The garbage collector will use about this much memory until the program residency grows and the heap size needs to be expanded to retain reasonable performance. However the actual behavior seems to be quite different. As an example, for a particular program: ./a.out +RTS -N7 -A256M -H2G uses around 7 GBytes of memory ./a.out +RTS -N7 -A256M -H6G uses around 13 GBytes of memory If the User's Guide is correct, changing -H2G to -H6G should not increase the heap usage beyond 6 GBytes. In the rts source, I see the parameter value (RtsFlags.GcFlags.heapSizeSuggestion) is used only to adjust the size of the allocation areas, not the entire heap. How is the -H option supposed to behave? How does it behave currently? Regards, Takano Akio

3 3

Re: [Haskell-cafe] Using MonadFix to tie the knot with STM
by Antoine Latter 17 Feb '11

17 Feb '11

On Sat, Feb 12, 2011 at 8:47 AM, Sebastiaan Visser <haskell(a)fvisser.nl> wrote: > Hi all, > > During a little experiment I discovered there is no MonadFix instance available for the STM monad. Is this absence the consequence of some deep restriction of how STM works or 'just accidental'? Is there some way I could derive this instance? If you port `fixST` to the STM monad, it seems to work fine at first glance: http://hpaste.org/43915/fixstm But I would want someone else's opinion on it to make sure I'm not doing something like introducing lazy STM values that violate atomicity, or something. The strict `case` on the return value makes me feel pretty good about it. Antoine > > For those who are interested and may know other ways to solve my problem, I'm trying to tie the knot in a graph by using transactional variables as the edges between nodes. I'm trying to do this in a rather generic way: > >> {-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable, StandaloneDeriving, DoRec #-} >> module Graph where >> >> import Control.Applicative >> import Control.Concurrent.STM >> import Control.Monad.Fix >> import Data.Maybe >> import Data.Foldable >> import Data.Traversable >> import Prelude hiding (mapM) >> import qualified Data.Map as M >> >> instance MonadFix STM where >> mfix = error "I need this instance!" -- What to do? >> >> -- A single node is a graph, has a list of both incoming and outgoing edges. >> >> data Node edge = Node >> { nodeId :: NodeId >> , payload :: String >> , incoming :: [edge] >> , ougoing :: [edge] >> } deriving (Functor, Foldable, Traversable) >> >> type NodeId = String >> >> -- A graph with an index on the nodes by NodeId, parametrized with the type we >> -- want to used as the edge pointer. >> >> type Graph edge = M.Map NodeId (Node edge) >> >> -- Type level fixed point combinator with a TVar annotation. >> >> newtype TFix f = TIn { tout :: TVar (f (TFix f)) } >> >> -- Take a graph that uses NodeIds as edges and recursively transform it into a >> -- graph with TVars to the neighbouring nodes in the edges. >> >> tieTheKnot :: Graph NodeId -> STM (Graph (TFix Node)) >> tieTheKnot untied = >> do rec tied <- (mapM . mapM) (\nodeid -> TIn <$> newTVar (tryLookup nodeid tied)) untied >> return tied >> >> -- Helper function to lookup a pre-tied node from a graph, throws an error when >> -- the edge could not be resolved. This should, of course, not happen! >> >> tryLookup :: NodeId -> Graph (TFix Node) -> Node (TFix Node) >> tryLookup i = fromJust (error msg) . M.lookup i >> where msg = "tieTheKnot: Lookup error, input is an incomplete graph." > > Thanks in advance, > > -- > Sebastiaan Visser > http://www.silkapp.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 2

Injective type families?
by Conal Elliott 16 Feb '11

16 Feb '11

Is there a way to declare a type family to be injective? I have > data Z > data S n > type family n :+: m > type instance Z :+: m = m > type instance S n :+: m = S (n :+: m) My intent is that (:+:) really is injective in each argument (holding the other as fixed), but I don't know how to persuade GHC, leading to some compilation errors like the following: Couldn't match expected type `m :+: n' against inferred type `m :+: n1' NB: `:+:' is a type function, and may not be injective I realize that someone could add more type instances for (:+:), breaking injectivity. Come to think of it, I don't know how GHC could even figure out that the two instances above do not overlap on the right-hand sides. Since this example is fairly common, I wonder: does anyone have a trick for avoiding the injectivity issue? Thanks, - Conal

8 9

Re: a compiled program is slower than byte code
by Simon Marlow 15 Feb '11

15 Feb '11

> If I compile the attach code with GHC of the newest ghc-7.0 darcs > branch, the compiled program is much slower than byte code. This > phenomenon does not exist in GHC 6.12.3. > > 6.12.3 runghc -- 6.23s user 0.59s system 98% cpu 6.912 total > ghc -- 5.72s user 0.70s system 99% cpu 6.422 total > ghc -O -- 5.70s user 0.67s system 99% cpu 6.376 total > ghc -O2 -- 5.69s user 0.67s system 99% cpu 6.373 total > > ghc-7.0 runghc -- 6.43s user 0.10s system 99% cpu 6.593 total > ghc -- 9.20s user 0.09s system 99% cpu 9.302 total > ghc -O -- 9.20s user 0.09s system 99% cpu 9.298 total > ghc -O2 -- 9.38s user 0.09s system 99% cpu 9.478 total > > Is this a bug? I don't see the same results here (x86_64/Linux). This is the 7.0 branch built last night: $ ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu [1 of 1] Compiling Main ( kazu.hs, kazu.o ) Linking kazu ... 8.58s real 8.54s user 0.04s system 99% ./kazu $ time runghc -f ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp; 16.92s real 14.21s user 2.70s system 99% runghc -f ghc-stable-nightly2 ./kazu.hs -O2 -fforce-recomp However, there is a fairly large difference between the 7.0 branch and HEAD: $ ghc-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu [1 of 1] Compiling Main ( kazu.hs, kazu.o ) Linking kazu ... 4.17s real 4.16s user 0.01s system 99% ./kazu HEAD is more than twice as fast on this program. Fusion not working, perhaps? Cheers, Simon > My environment is Mac which runs Snow Leopard. > > --Kazu > > ---- > import System.IO > > n :: Int > n = 10000 > > main :: IO () > main = withFile "/dev/null" WriteMode $ \h -> > hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a' > ----

2 4