- Glasgow-haskell-users

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

Oddity with 'cabal install' in GHC 7.4.1
by Conal Elliott 05 Feb '12

05 Feb '12

Since upgrading to 7.4.1, if I 'cabal install' successfully and then 'cabal install' a second time without first doing a 'ghc-pkg unregister <package-name>', I get the following complaint: cabal: The install plan contains reinstalls which can break your GHC > installation. You can try --solver=modular for the new modular solver that > chooses such reinstalls less often and also offers the --avoid-reinstalls > option. You can also ghc-pkg unregister the affected packages and run > ghc-pkg > check to see the effect on reverse dependencies. If you know what you are > doing you can use the --force-reinstalls option to override this reinstall > check. > The only path I've found so far that's willing to rebuild or even say nothing needs rebuilding (when nothing does) is to 'ghc-pkg unregister' and then 'cabal install' again. I'm getting the same behavior on Red Hat 5 and Mac OS 10.6.8, both compiled from sources. Does anyone know what's going on here? -- Conal

3 7

ANNOUNCE: GHC version 7.4.1
by Ian Lynagh 03 Feb '12

03 Feb '12

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.4.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC, 7.4.1. Here are some of the highlights of the 7.4 branch since 7.2 and 7.0: * The Num class no longer has Eq or Show superclasses. * There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe). The design has changed since 7.2. * There is a new feature kind polymorphism (-XPolyKinds). A side-effect of this is that, when the extension is not enabled, in certain circumstances kinds are now defaulted to * rather than being inferred. * There is a new feature constraint kinds (-XConstraintKinds). * It is now possible to give any sort of declaration at the ghci prompt. For example, you can now declare datatypes within ghci. * The profiling and hpc implementations have been merged and overhauled. Visible changes include renaming of profiling flags, and a new semantics for the cost-centre stacks (which should in most cases result in more useful and intuitive profiles). The +RTS -xc flag now also gives a stack trace. * It is now possible to write compiler plugins. * DPH support has been significantly improved. * There is now preliminary support for registerised compilation using LLVM on the ARM platform. Full release notes are here: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Impredicative types error
by John Meacham 01 Feb '12

01 Feb '12

Hi, I am running into an issue where some code that compiled and worked under 6.12 is failing under 7.0, the offending code is class DeNameable a where deName :: Module -> a -> a getDeName :: Tc (DeNameable n => n -> n) getDeName = do mn <- asks (tcInfoModName . tcInfo) return (\n -> deName mn n) Tc is a plain typechecking monad and this returns a generic denaming function that can be used to turn haskell names back into human readable form before printing errors in jhc. I have the ImpredicativeTypes LANGUAGE feature turned on. the error I get under 7.0 is src/FrontEnd/Tc/Monad.hs:131:29: Couldn't match expected type `n -> n' with actual type `DeNameable n' In the second argument of `deName', namely `n' In the expression: deName mn n In the first argument of `return', namely `(\ n -> deName mn n)' John

2 1