- Glasgow-haskell-users

Oversized libraries
by Audrius Šaikūnas 14 Dec '10

14 Dec '10

Hello, I've noticed that libraries that are compiled even with -dynamic are really huge: libHScairo-0.12.0-ghc6.12.1.so - 1.4 M libHSgio-0.12.0-ghc6.12.1.so - 1.6 M libHSgtk-0.12.0-ghc6.12.1.so - 14 M (ldd confirms that these libraries are really linked dynamically with the rest of the world) just to name a few. All of them are striped with "strip -s". At this point *bindings* to C libraries are larger that the libraries themselves, which I find unacceptable. So I decided to dig a bit deeper and when examining cairo-0.12.0 I found that Types.o object file consumes 1.5 MB. So I "cleaned" up Types.hs and tried to compile it separately from the rest of the library: % ghc -c Types.hs && ls -lh | grep Types.o -rw-r--r-- 1 angel angel 69K 2010-12-14 18:24 Types.o % rm Types.o % ghc -c Types.hs -O && ls -lh | grep Types.o -rw-r--r-- 1 angel angel 1.1M 2010-12-14 18:25 Types.o So adding -O when compiling Types.hs makes the size of object file jump from 69K to 1.1M. Just think about it - the file contains *two* *enums* and nothing more. And yet it twice as large as a full-blown application like gedit. So I would like to ask you whether such behavior is known and should such this be considered as a bug? I've attached the testcase. It also can be found here: http://hpaste.org/42331/something Btw, I'm using GHC 6.12.1, x86_64. Best regards, Audrius

3 2

HEAD doesn't build on OS X
by Johan Tibell 14 Dec '10

14 Dec '10

Starting with a clean tree I get: "/usr/bin/ghc" -H32m -O -Wall -Werror -H64m -O0 -package-conf libraries/bootstrapping.conf -package-name ghc-7.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.11.0 -package array-0.3.0.2 -package base-4.3.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.8 -package containers-0.4.0.0 -package directory-1.1.0.0 -package filepath-1.2.0.0 -package hpc-0.5.0.6 -package old-time-1.0.0.6 -package process-1.0.1.4 -package unix-2.4.1.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -DSTAGE=1 -no-user-package-conf -rtsopts -O -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/nativeGen/AsmCodeGen.lhs -o compiler/stage1/build/AsmCodeGen.o compiler/nativeGen/AsmCodeGen.lhs:83:1: parse error on input `*************' make[1]: *** [compiler/stage1/build/AsmCodeGen.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.0.1

1 0

Re: Functor => Applicative => Monad
by Antoine Latter 12 Dec '10

12 Dec '10

Is there a discussion deadline, if this now a libraries proposal? For something like this, you might want to advertise the discussion on Plane Haskell, and the -cafe to get adequate discussion, as it seems sure to break quite a few things. And reddit, although I consider that a less contemplative venue. Maybe other places? Do we know of any cases where this sort of conversion will be hard to do? This is also usually the part of the discussion where I would ask for an estimate as to how much this breaks what is published on Hackage, but I think the answer would be "a lot." If I depend on a prior version of the 'base' package, I'm guessing that I'm not insulated from this change, due to how de-sugaring happens. Do other haskell compilers (Hugs, NHC?) use the base library? How does this change affect them? Are there any ways to make this sort of change not break things? There has been talk about a language extensions to make this thing work out, but they have never been fleshed out, and they've always been the sort that sounded like they would have many corner cases. I don't like breaking things, even though the new hierarchy makes a lot of sense. Antoine On Sun, Dec 12, 2010 at 7:24 AM, John Smith <voldermort(a)hotmail.com> wrote: > On 12/12/2010 15:12, Bas van Dijk wrote: >> >> On Sun, Dec 12, 2010 at 12:48 PM, John Smith<voldermort(a)hotmail.com> >> wrote: >>> >>> There's a ticket at http://trac.haskell.org/haskell-platform/ticket/155, >> >> Thanks! But why create a ticket for the Haskell Platform? This is a >> change in the base library so we should follow the library submission >> process[1] and create[2] a ticket in the ghc trac. >> >> Regards, >> >> Bas >> >> [1] http://www.haskell.org/haskellwiki/Library_submissions >> [2] >> http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libra… > > Good point; I've moved it to http://hackage.haskell.org/trac/ghc/ticket/4834 > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

2 1

Re: Functor => Applicative => Monad
by Bas van Dijk 12 Dec '10

12 Dec '10

On Sun, Dec 12, 2010 at 12:48 PM, John Smith <voldermort(a)hotmail.com> wrote: > There's a ticket at http://trac.haskell.org/haskell-platform/ticket/155, Thanks! But why create a ticket for the Haskell Platform? This is a change in the base library so we should follow the library submission process[1] and create[2] a ticket in the ghc trac. Regards, Bas [1] http://www.haskell.org/haskellwiki/Library_submissions [2] http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libra…

1 0

Re: Functor => Applicative => Monad
by Bas van Dijk 12 Dec '10

12 Dec '10

On Wed, Dec 1, 2010 at 10:02 AM, John Smith <voldermort(a)hotmail.com> wrote: > Regarding recent concerns as to whether Pointed is actually useful (and if > it is, is that Pointed Functors or pure Pointed?), how about a slightly more > modest reform? > > class Functor f where > map :: (a -> b) -> f a -> f b > > class Functor f => Applicative f where > pure :: a -> f a > (<*>) :: f (a -> b) -> f a -> f b > (*>) :: f a -> f b -> f b > (<*) :: f a -> f b -> f a > > class Applicative m => Monad m where > (>>=) :: m a -> (a -> m b) -> m b > f >>= x = join $ map f x > > join :: m (m a) -> m a > join x = x >>= id > > (unrelated, but also valid) > > instance MonadPlus m => Monoid (m a) where > mempty = mzero > mappend = mplus > > > module Legacy where > > fmap :: Functor f => (a -> b) -> f a -> f b > fmap = map > > liftA :: Applicative f => (a -> b) -> f a -> f b > liftA = map > > liftM :: Monad m => (a -> b) -> m a -> m b > liftM = map > > ap :: Monad m => m (a -> b) -> m a -> m b > ap = (<*>) > > (>>) :: Monad m => m a -> m b -> m b > (>>) = (*>) > > concat :: [[a]] -> [a] > concat = join > > etc. > > And for those who really want a list map, > > listMap :: (a -> b) -> [a] -> [b] > listMap = map > Linked are some patch bundles that provide an initial implementation of the new hierarchy: * http://code.haskell.org/~basvandijk/ghc_new_monad_hierarchy.dpatch This patch bundle is to prepare ghc for the new hierarchy. Most importantly it adds Functor and Applicative instances for all monads in ghc. Note that these patches are useful on their own and don't depend on the new hierarchy so they can be applied even when this proposal is not accepted. * http://code.haskell.org/~basvandijk/base_new_monad_hierarchy.dpatch This patch actually implements the new hierarchy. I tried to be even more conservative than the current proposal, namely 'return' and '>>' are still methods of Monad but have now been given default implementations in terms of Applicative. Also all names have been kept intact (fmap is still named fmap): class Functor f where fmap :: (a -> b) -> f a -> f b (<$) :: a -> f b -> f a (<$) = fmap . const class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b a *> b = fmap (const id) a <*> b (<*) :: f a -> f b -> f a a <* b = fmap const a <*> b class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b m >>= f = join $ fmap f m join :: m (m a) -> m a join m = m >>= id (>>) :: m a -> m b -> m b (>>) = (*>) return :: a -> m a return = pure fail :: String -> m a fail s = error s Also see the generated library documentation: http://bifunctor.homelinux.net/~bas/doc/ghc/html/libraries/base-4.4.0.0/ Note that I am in favour of removing 'return', '>>' and 'fail' from Monad and renaming 'fmap' to 'map'. But I think it's better to do this as a separate patch. Besides patching the base library and ghc, I also needed to patch lots of other libraries in my ghc root. To get these patches, simply pull from my local ghc repository. i.e.: darcs pull http://bifunctor.homelinux.net/~bas/ghc/ darcs pull http://bifunctor.homelinux.net/~bas/ghc/libraries/base Note that ghc requires the happy parser generator. When happy generates a parser it also generates a HappyIdentity type with an according Monad instance. The following patch makes happy also generate the needed Functor and Applicative instances (This patch is already send to happy's maintainer): http://bifunctor.homelinux.net/~bas/functor_and_applicative_instance_HappyI… Feel free to ask questions or post comments about these patches. Regards, Bas P.S. John, did you already make a ticket for this proposal? I would like to attach my patches to it.

1 0

Re: [darcs-users] How to develop on a (GHC) branch with darcs
by Ganesh Sittampalam 10 Dec '10

10 Dec '10

On Wed, 8 Dec 2010, Stephen J. Turnbull wrote: > Ganesh Sittampalam writes: > > > I think there are three things that can help with this problem: > > > > 1) a darcs rebase command. This will give you a nice way to manage the > > workflow already discussed, and you won't have to squish everything > > through into a mega-patch. You'll still have to periodically abandon one > > branch for another though (but I think that's also the case with git > > rebase). > > I'm not sure what you mean by "abandon". I mean the same as in the git world. The rebased patches have new identities, and if my ideas for tracking the relationship don't work out, they will have no relationship to the old patches. [your very clear explanation of that snipped] > > I also have some hope, though this is more speculative, of offering > > a clean way of tracking the relationship between the old branch and > > the new branch so that any stray patches against the old branch can > > be cleanly rebased to the new branch later on. > > As explained above, DAG-based VCSes like git can't do this cleanly > (that is one way of expressing the reason why rebase is severely > deprecated in some circles), and I don't think git will be able to do > so in the near future. OTOH, if Darcs gets rebase but can't handle > this, I'd have to count that as a net minus. Recombinant patching is > really what Darcs is all about IMO. darcs rebase is essentially about giving up on the recombinant patching because that's not working out for whatever reason. It's primarily intended as an alternative to manually reapplying patches to new branches using diff-and-patch, which is something significant numbers of people have ended up having to do. People generally want/need to do this to avoid conflicts, because: (a) darcs conflict handling can blow up, both because of exponential merges (primarily with v1 patches) and because of bugs (b) the UI for dealing with conflicts isn't really that pleasant and in particular once you've resolved a conflict it's a little painful to see the overall effect of the conflict resolution together with the underlying patch > In practice, git rebase needs to be kept private to a single user, and > is impractical even if private, if the user has propagated the branch > to other local repositories. Because git branching is so lightweight, > nobody really sees this as a big problem; throwaway branches are used > all the time as interim steps in many operations (eg, git stash). > Darcs branches, on the other hand, are much more heavyweight (modulo > the work you propose on colocated branches, but that's farther away > than rebase is). > > IMHO YMMV. But I strongly recommend you think carefully about this. > Analogies to git rebase are a trap here. It's implemented differently > and used to solve different problems from the way rebase is proposed > for use in Darcs. My understanding is that one of the main uses for git rebase is for "cleaning up history" prior to submission. In that regard I think there's a substantial overlap with what darcs rebase is intended for. Thanks for the detailed comments. Ganesh

1 0

How to use llvm with ghc7?
by Magicloud Magiclouds 10 Dec '10

10 Dec '10

Hi, I just got ghc7 and compiled with ghc6.12.1 and default configuration. ghc works fine. So I tried to use llvm. I got: ghc -fllvm badge.hs [1 of 1] Compiling Main ( badge.hs, /tmp/Main.o ) opt: Bitcode stream should be a multiple of 4 bytes in length I am using debian 32bit system, llvm 2.6. -- 竹密岂妨流水过山高哪阻野云飞

2 2

New flag in GHC 7.0.1: --with-rtsopts
by Simon Marlow 09 Dec '10

09 Dec '10

It seems we forgot to mention in the 7.0.1 release notes that there's a new compile-time flag, --with-rtsopts. From the documentation: 4.16.8. Linker flags to change RTS behaviour GHC lets you exercise rudimentary control over the RTS settings for any given program, by using the -with-rtsopts linker flag. For example, to set -H128m -K1m, link with -with-rtsopts="-H128m -K1m". Cheers, Simon

1 0

How to develop on a (GHC) branch with darcs
by Iavor Diatchki 08 Dec '10

08 Dec '10

Hello, I am doing some work on a GHC branch and I am having a lot of troubles (and spending a lot of time) trying to keep my branch up to date with HEAD, so I would be very grateful for any suggestions by fellow developers of how I might improve the process. Here is what I have tried so far: First Attempt ~~~~~~~~~~~~~ My branch, called 'ghc-tn', was an ordinary darcs repo. I recorded my changes as needed, and every now and then would pull from the HEAD repo. If conflicts occurred, I would resolve them and record a patch. Very quickly I run into what, apparently, is a well-known darcs problem where trying to pull from HEAD would not terminate in a reasonable amount of time. Second Attempt ~~~~~~~~~~~~~~ Avoid "conflict patches" by constantly changing my patches. This is how I've been doing this: Initial state: ghc: a repository with an up-to-date version of GHC head ghc-tn: my feature repo based on a slightly out-of-date GHC HEAD. Goal: Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch) Process: 1. Create a temporary repository for the merge: darcs clone --lazy ghc ghc-tn-merge 2. Create a backup of the feature branch (strictly speaking not necessary but past experience shows that it is a good idea to have one of those). darcs clone --lazy ghc-tn ghc-tn-backup 3. Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time. darcs pull ghc-tn y d 3.1. If a feature patch causes a conflict, then resolve the conflict and create a new patch, obliterating the old one: darcs amend-record (creates a new patch, not a conflict patch, I think) After repeating this for all branch patches, I have an updated branch in 'ghc-tn-merge' with two caveats: 1. The new repository does not contain my previous build so I have to re-build the entire GHC and libraries from scratch. This is a problem because GHC is a large project and rebuilding everything takes a while, even on a pretty fast machine. I work around this problem like this: 1.1 Obliterate all branch patches from 'ghc-tn'. This, essentially, rewinds the repository to the last point when I synchronised with HEAD. To do this properly I need to know which patches belong to my branch, and which ones are from GHC. (I've been a bit sloppy about this--- I just use the e-mails of the branch developers to identify these and then look at the patches. A better way would be to have some kind of naming convention which marks all branch patches). 1.2 Pull from 'ghc-tn-merge' into 'ghc-tn'. By construction we know that this will succeed and reintroduce the feature changes, together with any new updates to GHC into 'ghc-tn'. Now 'ghc-tn-merge' and 'ghc-tn-backup' can be deleted. 2. The new repository contains rewritten versions of the branch patches so---if I understand correctly---it is not compatible with the old one (i.e., I cannot just push from my newly updated branch to the public repo for my branch as there will be confusion between the old feature patches and the new ones). I can think of only one solution to this problem, and it is not great: 2.1 Delete the original public repo, and publish the new updated repo, preferably with a new name. In this way, other developers who have the old patches can either just clone the new repo, or go through steps 1.1--1.2 but will not accidentally get in a confused state by mixing up the new feature patches with the old ones. For background, my solution is essentially a manual implementation of what is done by git's "rebase" command---except that there "branch patches" and various "repository states" are automatically managed by the system so there is no need to follow various naming conventions which tend to be error prone. Apologies for the longish e-mail but this seems like an important problem and I am hoping that there's a better way to do things. -Iavor

9 8

Parallel, Incremental Linking
by John Smith 07 Dec '10

07 Dec '10

The bottleneck for building on my multi-core machine is ld, which spends a considerable time consuming 100% of one core after ghc has finished generating object files. Moreover, GHC is largely IO bound, while ld is CPU bound; incremental linking would enable the two tasks to be performed in parallel (or am I being naive?) Gold in an incremental and multi-threaded linker, but can only output ELF (not Windows). Is there a cross-platform solution suitable for GHC?

4 3