- Glasgow-haskell-users

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

Re: [Haskell-cafe] Some thoughts on Type-Directed Name
by Anthony Clayden 31 Jan '12

31 Jan '12

> There is an effort underway to make Haskell's Records > better. The discussion is ongoing on the ghc-users mail > list, ... > in the direction of making the most minimal changes > possible to achieve some simple record name-spacing. > > Thanks, > Greg Weber Thank you Greg, Yes I know, and I have been trying to follow along (intermittently). Thank you for your attempts to marshall the discussion. What would really, really help me is for someone to have a look at the 'solution' I posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to Steve.) It seemed from my testing to address the needs. Since I got it working in GHC 7.2.1, there's a good chance it will need only "minimal changes" to implement (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and generalisable enough. It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ used, but wasn't available to me at the time). I keep trying to make the time to write up the full proposal on the Wiki. I see it as a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to make time until/unless someone else double-checks whether I'm barking up the wrong tree. Anthony

3 2

ghc needs memory
by John Meacham 30 Jan '12

30 Jan '12

So... I knew that ghc was a memory hog.. but I am suddenly running into it dying with messages like the following: ghc: out of memory (requested 5997056753664 bytes) make[1]: *** [jhc] Error 1 Before I go out and find a machine with 6 terrabytes of RAM, I figured I'd post here first :) now the strange thing is, this started happening at the same time for both ghc 6.12.1 and 7.0.x (will report exact version later) so clearly something about my code is tickling ghc the wrong way. Though, ghc 7.0.x is slightly better in that it requests only one and a half terrabytes of ram :) Hmm.. I will try to track down a smaller test case, or narrow down what change caused it, but everything looks quite benign. I did recently add NoMonomorphismRestriction, NoMonoLocalBinds, and OverloadedStrings to my standard options, which is the only global change across the board I can think of... John

2 2

ghc-7.4.1-rc1 recompilation checking
by Christian Maeder 30 Jan '12

30 Jan '12

Hi, full recompilation with ghc-7.4.1-rc1 is already triggered by a changed "-o" option, which is inconvenient when creating different binaries with shared modules. (see below) It is no problem if I always omit the -o option and get binaries named like my input file, though. Can/should this behaviour of ghc-7.4 be relaxed? Cheers Christian -bash-3.00$ ghc B -o b [1 of 2] Compiling C ( C.hs, C.o ) [2 of 2] Compiling Main ( B.hs, B.o ) Linking b ... -bash-3.00$ ghc A -o a [1 of 2] Compiling C ( C.hs, C.o ) [2 of 2] Compiling Main ( A.hs, A.o ) Linking a ...

3 4

Error when deriving Typeable for associated type
by Bas van Dijk 30 Jan '12

30 Jan '12

Hello, Given the following program: ----------------------------------------------------------- {-# LANGUAGE DeriveDataTypeable, TypeFamilies #-} import Data.Typeable class C a where data T a :: * data MyType1 = MyType1 deriving Typeable data MyType2 = MyType2 deriving Typeable instance C MyType1 where data T MyType1 = A1 deriving (Typeable) instance C MyType2 where data T MyType2 = A2 deriving (Typeable) ----------------------------------------------------------- I get the following unexpected error: TF_Data.hs:12:34: Duplicate instance declarations: instance Typeable1 T -- Defined at TF_Data.hs:12:34 instance Typeable1 T -- Defined at TF_Data.hs:15:34 When looking at the output of -ddump-deriv I see that the following instance is generated: instance Typeable1 T where ... I would have expected that the following instances were generated instead: instance Typeable1 (T MyType1) where ... instance Typeable1 (T MyType2) where ... Is this a bug in GHC? Thanks, Bas

1 0

7.4.1-candidate-2
by Serge D. Mechveliani 29 Jan '12

29 Jan '12

Dear GHC team, I have tested ghc-7.4.0.20120126 on Linux Debian, i-386-like by the following tests. 1. Making it by ghc-7.4.0.20111219. 2. Making it by itself. 3. Making random-1.0.1.1. 4. Making and running the DoCon-2.12 test. 5. Making and running an example under DoCon-2.12 under -prof (one point of SCC, without careful investigation). It looks all right. Notes ----- Making each new ghc version now needs also re-make of Ramdom before making DoCon. In ghc-7.4.0.20111219 the minimal `-M' for the DoCon test running is -M2600k, In ghc-7.4.0.20120126 it is -M2400k; and the time is 3.6 sec instead of 3.8, and ghc-7.4.1 has the same measure results as ghc-7.4.0.20120126. Reards, ------ Sergei mechvel(a)botik.ru

1 0