February 2012 - Glasgow-haskell-users

Taking binary from hackage or GHC?
by Joachim Breitner 08 Feb '12

08 Feb '12

Dear interested parties :-), GHC 7.4.1 started to ship and expose the binary library, version 0.5.0.3. On hackage is binary-0.5.1.0. In Debian, we try to provide one version of each library, so we have to decide: * Use the version provided by GHC and drop the independent binary package (as we have done with random, for example). * Do not expose binary in GHC and continue using the version from hackage. @Upstream: Do you think binary on hackage will diverge much from the one in GHC and would you expect your users to want the new versions before they are shipped with GHC? And do you expect breakage in any components (e.g. haddock) if everything but GHC uses a newer binary package? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

3 3

[CFARM-REQUEST] GHC build bots on CompileFarm?
by Joachim Breitner 07 Feb '12

07 Feb '12

Dear Laurent, I’m one of the Debian maintainers of the main Haskell compiler GHC. GHC itself has little resources to maintain GHC on exotic architectures, but Debian tries hard to provide a Haskell ecosystem on these. It would help a lot if there were GHC buildbots on these architectures, and I would like to volunteer to manage these, but I’m still looking for suitable hardware. Note that GHC is a big beast, it takes 29h and requires 4GB free disk space and preferably something around 6GB of RAM to build on a arm box.I think you need to take that into account when deciding upon this request. I’d already be happy if I can do a test run every week or so. GHC is BSD licensed (http://www.haskell.org/ghc/license) my contributions are mostly Debian package maintenance and a few minor patches. Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

ghc -C in 7.4.1
by Serge D. Mechveliani 07 Feb '12

07 Feb '12

Dear GHC team, I needed to look into the C code made by ghc-7.4.1 (made from source by 7.0.1 on Debian Linux) for module TT (dropCWhile) where dropCWhile :: (Char -> Bool) -> [Char] -> [Char] dropCWhile p xs = case xs of [] -> [] x: ys -> if p x then dropCWhile p ys else xs And applied ghc -C -O TT.hs It reports ------------------------------------------- addFlag by -C on the commandline: Warning: The -fvia-C flag does nothing; it will be removed in a future GHC release ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): pipeLoop: at phase As but I wanted to stop at phase HCc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ------------------------------------------- 1. A bug report. 2. How to see this C code? What GHC version shows it? If you have such a version installed, can you, please, send me the C code? Regards, ------ Sergei mechvel(a)botik.ru

3 2

via-C
by Serge D. Mechveliani 06 Feb '12

06 Feb '12

Dear GHC team, I cannot understand why do you remove the C stage in GHC. To my mind: let the result be 3 times slower, but preserve the C code. Because it works everyhere, and there is no real need to rewrite the same program separately for all the existing processors (which number may become, for example, 11000). I am naive, and am not a specialist. But only an invariant program ever has sense. Has the modern GHC a sensible compilation result level to be observed (documented?) (graph rewriting code, or like this) ? Regards, ------ Sergei mechvel(a)botik.ru

7 7

`unregisterised' performance
by Serge D. Mechveliani 06 Feb '12

06 Feb '12

Dear GHC team, I have compared for performance on DoCon of ghc-7.4.1 registerised and unregisterised, both made from source by ghc-7.4.1 (Debian Linux, GenuineIntel, Intel(R) Core(TM)2 CPU), DoCon and its test compiled under -O (-O2 is not better than -O). `registerised' is 5.4 times faster in building DoCon, is 3 times faster in running the DoCon test, produces 1.7 times smaller .a library file for DoCon. All right. Please, keep on supporting the portable (via-C) branch. Regards, ------ Sergei mechvel(a)botik.ru

1 0

unregisterized
by Serge D. Mechveliani 06 Feb '12

06 Feb '12

People, Please, where the build guide (.pdf, .html) can be download from? Does the source GHC distibution include the build guide? Does the GHC user_guide include the build guide? If not, then -- why? How to build unregisterized ghc-7.4.1 from source? (For many years I read "registerized" in the GHC related messages as "registered" and wondered of why do they care for a user to register a build!) Thanks, ------ Sergei mechvel(a)botik.ru

3 3

Re: unregisterised and -prof
by Christian Höner zu Siederdissen 06 Feb '12

06 Feb '12

It would seem that you are building random with profiling enabled: 4. Build random-1.0.1.1 by new by ghc/7.4.1/instUnregis by ghc --make Setup ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p ./Setup build -v while your non-reg'ged build of ghc has no profiling libraries. At least that is what this error says: * Serge D. Mechveliani <mechvel(a)botik.ru> [06.02.2012 18:20]: > > System/Random.hs:97:8: > Could not find module `Numeric' > Perhaps you haven't installed the profiling libraries for package `base'? > Use -v to see a list of the files searched for. > scico:~/ghc/random/random-1.0.1.1> > ------------------------------------------------------------ The easiest is to remove the "-p" flag, if you do not need profiling enabled. Gruss, Christian

1 0

unregisterised and -prof
by Serge D. Mechveliani 06 Feb '12

06 Feb '12

Dear GHC team, For some reason ghc-7.4.1-unregisterised cannot build random-1.0.1.1 -- unlike ghc-7.4.1-default. This is for ghc-7.4.1 built from source by ghc-7.4.1 on Debian Linux, i386-uknown. 1. I build ghc-7.4.1 from source under the default flags, by ghc-7.4.1, under configure --prefix=/home/mechvel/ghc/7.4.1/inst 2. Build ghc-7.4.1 from source by new by ghc/7.4.1/inst as unregisterised by setting configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis , ----------- setting BuildFlavour = unreg in mk/build.mk by un-commenting this line. 3. Build random-1.0.1.1 by ghc of 7.4.1/inst by ghc --make Setup ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/inst/lib/ghc-7.4.1 -p ./Setup build -v ./Setup haddock ./Setup install -v It is built all right. 4. Build random-1.0.1.1 by new by ghc/7.4.1/instUnregis by ghc --make Setup ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p ./Setup build -v It reports ----------------------------------------------------------------------- scico:~/ghc/random/random-1.0.1.1> ./Setup configure --prefix=/home/mechvel/ghc/7.4.1/instUnregis/lib/ghc-7.4.1 -p Configuring random-1.0.1.1... scico:~/ghc/random/random-1.0.1.1> ./Setup build -v creating dist/build creating dist/build/autogen Building random-1.0.1.1... Preprocessing library random-1.0.1.1... Building library... creating dist/build /home/mechvel/ghc/7.4.1/instUnregis/bin/ghc --make -package-name random-1.0.1.1 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.5.0.0-c8e7184681d410015e93df85fc49e9dd -package-id time-1.4-3e186a51d3674e5d65b5a7925db3d3a7 -O -O2 -XHaskell98 -XCPP System.Random [1 of 1] Compiling System.Random ( System/Random.hs, dist/build/System/Random.o ) /home/mechvel/ghc/7.4.1/instUnregis/bin/ghc --make -package-name random-1.0.1.1 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.5.0.0-c8e7184681d410015e93df85fc49e9dd -package-id time-1.4-3e186a51d3674e5d65b5a7925db3d3a7 -O -O2 -XHaskell98 -XCPP System.Random -prof -hisuf p_hi -osuf p_o System/Random.hs:97:8: Could not find module `Numeric' Perhaps you haven't installed the profiling libraries for package `base'? Use -v to see a list of the files searched for. scico:~/ghc/random/random-1.0.1.1> ------------------------------------------------------------ Should I set something more in mk/build.mk than un-commenting the line #BuildFlavour = unreg ? Please, what I am missing? Thanks, ------ Sergei mechvel(a)botik.ru

1 0

Re: Oddity with 'cabal install' in GHC 7.4.1
by Conal Elliott 06 Feb '12

06 Feb '12

Ah -- so use cabal-dev for development and cabal-install when a version stabilizes? -- Conal On Sun, Feb 5, 2012 at 4:20 PM, Jason Dagit <dagitj(a)gmail.com> wrote: > On Sun, Feb 5, 2012 at 10:48 AM, Conal Elliott <conal(a)conal.net> wrote: > > On Sun, Feb 5, 2012 at 12:43 AM, Andres Löh <andres.loeh(a)googlemail.com> > > wrote: > >> > >> Hi Conal. > >> > >> > Thanks for the reply! Note that I get this message even running 'cabal > >> > install' a second time after changing nothing. Is that scenario an > >> > example > >> > of what you mean by a "potentially dangerous cabal invocation"? > >> > >> The check currently is entirely ad-hoc. Any reinstallation of an > >> existing package triggers the warning. There's no hash comparison. > > > > > > I'm confused. Isn't package re-installation an extremely common thing in > > cabal while developing software? > > I would say, "You should never mutate your user or global package > database" and recommend using cabal-dev. The way cabal-install does > destructive updates is evil. In particular, it likes to mutate your > global or user package database. You run the risk of building > something and then breaking it later by mutating its dependencies. > > With cabal-dev it would be more like this: > # Suppose you're in the source of bar > # Further suppose you just changed > # dependency 'foo' that you're also developing > cabal-dev add-source ../foo > cabal-dev install --reinstall foo > > Technically this still mutates a package database but, it's a > throwaway package database in the bar directory. I lose very little > when I 'rm -rf cabal-dev dist' and my user and global package > databases stay in tact. I feel as though I can't sing the > sandboxed-build praise loudly enough. The time my computer takes to > rebuild packages is negligible to the human time spent dealing with > broken package databases.. > > I hope that helps, > Jason >

1 0

Haddock problems with GHC 7.4.1
by Conal Elliott 05 Feb '12

05 Feb '12

Since installing GHC 7.4.1 (from sources), I'm getting lots of complaints from 'ghc-pkg check', of the following form: Warning: haddock-interfaces: > /usr/local/share/doc/transformers-0.2.2.0/html/transformers.haddock doesn't > exist or isn't a file > Warning: haddock-html: /usr/local/share/doc/transformers-0.2.2.0/html > doesn't exist or isn't a directory > Happens both on (Red Hat) Linux 5 and Mac OS 10.6.8. Any advice? -- Conal

2 2