April 2014 - Glasgow-haskell-users

Fwd: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64
by Ramin Honary 14 Apr '14

14 Apr '14

Hi, thanks for your reply. Yes, I know for a fact I was installing to the global registry. All of my Haskell projects depend on a few important packages, and I always install these globally. For stuff I just want to play around with, I just install into the user registry. Actually terminfo-0.4.0.0 is not something any of my projects depend on, but I had installed it globally anyway and then this problem occurred. Also, the behavior Cabal installing Crypto-4.2.5.1 was odd. As I explained in my first e-mail, some of the shared modules were being built with file extensions of ".hi" instead of ".dyn_hi", but the "copy" phase of the Cabal installation was searching for files with ".dyn_hi" extensions and was failing. And not all modules were being built incorrectly, some modules had the correct ".dyn_hi", others had just ".hi". This may be a problem with the Crypto.cabal file, however. But anyway, the transition to using shared libraries by default has (in my experience) caused just these two hiccups. I'm glad I was able to expose this problem. -- Ramin Honary On Mon, Apr 14, 2014 at 10:07 PM, Austin Seipp <austin(a)well-typed.com>wrote: > Hi Ramin, > > Can I ask if you're installing packages into the global user database? > If so, that's definitely the way for this to happen - otherwise, Cabal > should never overwrite *anything* in the 'global' package directory > (in your case, under /usr/local/lib/ghc-7.8.2...) This is the only way > I can see this happening. In particular, installing 'terminfo' into my > local package database ('cabal install terminfo') works fine... > > Carefully review your cabal configuration if you don't mind. You can > also always force the installation using '--user' when running cabal. > > However, thank you very much for bringing this to my attention. What > you have discovered is a real brainfart I don't think we had > considered! The problem is that now that GHC is dynamically linked, we > *cannot* get away with lying about whether those packages are > installed - because they must install shared objects for GHC itself to > work. That means overwriting them by accident (because we don't think > they're installed) is a real possibility. > > Relatedly, the NixOS Haskell users are suffering from the same problem > with 7.8.2 - > http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012992.html > - same problem, slightly different symptoms. > > See https://ghc.haskell.org/trac/ghc/ticket/8919 for the ticket. > > So this is definitely a real problem. I think scheduling the change > for 7.8.3 is correct. > > My intuition tells me the fix might actually be quite simple - don't > lie about xhtml and terminfo being installed, and just be honest. Is > there any particular downside to doing this? I don't think so, *other* > than the fact it does mean terminfo has to come along when it's not > part of the Haskell Platform! > > > > On Mon, Apr 14, 2014 at 7:08 AM, Ramin Honary <ramin.honary(a)gmail.com> > wrote: > > I am using Debian, not Mac. It is possible the problem may be with the > > binary release for Debian x86_64, or it could just be my Cabal config > file. > > > > When I install the binary distribution onto Debian, I simply run "make > > install" in the ghc-7.8.2 directory. I don't know how this install > process > > the creates the GHC package registry, but after a fresh install, the > output > > of the "ghc-pkg list" command shows that "terminfo-0.4.0.0" is NOT > installed > > even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory > > clearly exists and is populated with the correct library files. But > since it > > is not registered Cabal tries to re-build it and overwrites the existing > > "terminfo-0.4.0.0" package. > > > > After a fresh install on Mac or Fedora, I wonder if "terminfo-0.4.0.0" > shows > > up in the GHC package registry? It could be the package registry for the > > Debian binary distribution missed that detail. > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ >

1 0

Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64
by Ramin Honary 14 Apr '14

14 Apr '14

I am posting this to the mailing list, but it is a copy of a post I originally made on Haskell Reddit. http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782… My GHC is working fine now. But there seem to be some changes in either GHC 7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in Hackage. *TL;DR* I discovered the "Crypto-4.2.5.1 package is broken, and trying to install "terminfo-0.4.0.0" breaks GHC by over-writing the terminfo library that came with the GHC tarball because isn't in the GHC package registry. I downloaded the binary distribution from here: https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.… and then immediately began re-building all of the packages in my .cabal/packages/hackage.haskell.org/ direcotry. I admit, all of my problems may be due to my Cabal config, but I haven't had any problems with it before this, as far as I know it is the default setup the option to build profiling libraries set to True. The first problem I had was that Crypto-2.5.4.1 was not building files correctly. *Some* of shared object files "*.dyn_o" were being built *without* their accompanying "*.dyn_hi" files, although some of the "*.dyn_hi" files did exist). When cabal tried to copy these "*.dyn_hi" files to the global package registry during installation it would fail with something about (for example) "could not find RSA.dyn_hi". To solve this, I rebuilt every "*.dyn_o" file that did not have an accompanying "*.dyn_hi" by hand using the command ghc -dynamic --make Codec.Binary.RSA The resulting "Codec/Binary/RSA.hi" file was actually a dynamic interface file but it's file extension was just ".hi" for some reason, (I double checked by using ghc --show-iface) so I just copied it it the "dist/build/Codec/Binary/" directory. I did this for every "*.hi" file that was supposed to be named "*.dyn_hi". This included about 10 files. Again, some "*.dyn_o" did build correctly with an accompanying "*.dyn_hi", about 10 of the modules were built incorrectly, all the rest were OK. The second problem I had was with installing "Yi" which relies on the "terminfo-0.4.0.0" package. The "terminfo" library that came with the GHC 7.8.2 binary distribution does not show up in the output of "ghc-pkg list", so Cabal tries to build it thinking it doesn't exist, and it overwrites the existing "terminfo-0.4.0.0" package with a library that contains missing symbols. This causes GHC to completely stop working. The "ghc" program immediately fails with an error: symbol lookup error: /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so: \ undefined symbol: terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info I was able to solve this problem by simply copying the contents of: ghc-7.8.2/libraries/terminfo/dist-install/build/* from the source distribution tarball to the GHC installation directory: /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/ and that solved the problem. But any program depending on "terminfo" simply will not install properly. The terminfo-0.4.0.0 package does not show up in the output of ghc-pkg list, even though it comes with the GHC 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will build a ".so" file that GHC cannot use. *So don't install terminfo-0.4.0.0 from Hackage.* Fortunately, Yi is not something that is absolutely necessary. I was able to install every other package I needed (lens, diagrams, yesod, xmonad, gtk) without incident. But whatever changes have been made in ghc-7.8.2 and the accompanying Cabal-1.18.1.3 seem to have broken some of the older Hackage packages.

3 3

ANNOUNCE: GHC version 7.8.2
by Austin Seipp 14 Apr '14

14 Apr '14

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.2. This is an important bugfix release relative to 7.8.1, so we highly recommend upgrading from 7.8.1. The full release notes are here: https://www.haskell.org/ghc/docs/7.8.2/html/users_guide/release-7-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://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://ghc.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://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners 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://ghc.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://ghc.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 Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

can't load .so/.DLL - undefined symbol
by Henning Thielemann 11 Apr '14

11 Apr '14

I am trying to understand the following linker message. I have started GHCi, loaded a program and try to run it: Main> main ... Loading package poll-0.0 ... linking ... done. Loading package alsa-seq-0.6.0.3 ... can't load .so/.DLL for: /var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so (/var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so: undefined symbol: alsazmseqzm0zi6zi0zi3_SystemziPosixziPoll_zdfStorableFd_closure) I assume that GHCi wants to say the following: The instance Storable Fd defined in module System.Posix.Poll cannot be found in the shared object file of the alsa-seq package. That's certainly true because that module is in the package 'poll' and not in 'alsa-seq'. But 'alsa-seq' imports 'poll'. What might be the problem? It's a rather big example that fails here, whereas the small examples in alsa-seq package work. Thus I first like to know what the message really means, before investigating further. I installed many packages at once with cabal-install using a single build directory, like: $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll alsa-seq pkg1 pkg2 pkg3 ... ? Can this cause problems?

2 3

GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check'
by Conal Elliott 10 Apr '14

10 Apr '14

I installed the binary distribution of GHC 7.8.1 for Mac OS this morning, cabal-installed a few packages, and now I get a *lot* of warnings about missing .haddock files: bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory ... Expected behavior? Avoidable? Fixable? Thanks, - Conal

3 5

7.8.1 cabal install of vector package (dependent on primitive package) fails
by Vivian McPhail 10 Apr '14

10 Apr '14

Hi, Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following: # cabal install --global vector ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: vector-0.10.9.1 failed during the building phase. The exception was: ExitFailure 1 Cheers, Vivian

6 7

Re: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.8.1
by Kazu Yamamoto 10 Apr '14

10 Apr '14

>> * Massive scalability improvements to the I/O manager > > Just a brief note from the front lines - I recompiled a heavily threaded > program with (a recent pre-release) of 7.8.1 and got a 10% performance > increase over 7.6.3. Nothing like free lunches - so thanks again for > the great work! Did you run you program on a multicore system? If so, did you specify +RTS -N<x> option? If your program uses MVar heavily, you need to re-design your program. For more information, please read: http://www.yesodweb.com/blog/2014/01/new-fast-logger --Kazu

1 0

ANNOUNCE: GHC version 7.8.1
by Austin Seipp 09 Apr '14

09 Apr '14

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * New type-system features * Closed type families * Role checking * An improved solver for type naturals * Better support for cross compilation * Full iOS support * Massive scalability improvements to the I/O manager * Dynamic linking for GHCi * Several language improvements * Pattern synonyms * Overloaded list syntax * Kind-polymorphic 'Typeable' class * A new parallel --make mode * Preliminary SIMD intrinsic support * A brand-new low level code generator * Many bugfixes and other performance improvements. The full release notes are here: http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-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://ghc.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://ghc.haskell.org/trac/ghc/wiki/TeamGHC 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://ghc.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://ghc.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 Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

GHC API: getting the unfolding of a "strange" Id
by Christiaan Baaij 04 Apr '14

04 Apr '14

Dear list, I'm using the GHC API to get Core Expressions from haskell interface (.hi) files, and have encountered a strange kind of 'Id' for which I can't seem to get the unfolding: The properties of this 'Id' are the following: - varName: $fNumFixed2 - IdDetails: VannillaId - Pretty print of IdInfo.inlinePragInfo: [Always] - IdInfo.unfoldingInfo: NoUnfolding The source file which gives rise to this 'Id' is: https://github.com/christiaanb/clash-prelude/blob/master/src/CLaSH/Sized/Fi… As you can see, the file is compiled with: -fexpose-all-unfoldings The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would expect to have a usable 'Unfolding' in general. How can GHC inline the body of this 'Id' if it has no unfolding? Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the $fNumFixed2 'Id' is no longer included in the interface file. At positions where "$fNumFixed2" was originally used, a equality constraint can eventually be found: Using -O: (CLaSH.Sized.Fixed.$fNumFixed2 @(GHC.TypeLits.+ 4 4) Using -O0 -fno-omit-interface-pragmas: (GHC.Types.Eq# @GHC.Types.Bool @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) @GHC.Types.True _CO_) So my question is, what kind of "strange" 'Id' is this $fNumFixed2? And how can I get the Core expression for this 'Id' from the interface file? And if I can't get it from the interface file, is there a straightforward way to generate it from the 'Id'? Cheers, Christiaan

2 6

Bang Patterns
by Dan Doel 02 Apr '14

02 Apr '14

Greetings, I've been thinking about bang patterns as part of implementing our own Haskell-like compiler here, and have been testing out GHC's implementation to see how it works. I've come to one case that seems like it doesn't work how I think it should, or how it is described, and wanted to ask about it. Specifically, consider: case Nothing of !(~(Just x)) -> 5 Nothing -> 12 Now, the way I'd expect this to work, and how I think the spec says it works, is that my Nothing is evaluated, and then the irrefutable ~(Just x) matches Nothing, giving a result of 5. In fact, GHC warns about overlapping patterns for this. However, this actually evaluates to 12, meaning that !(~p) appears to cancel out and be equivalent to p. It seems to me this might be a side effect of the logic used to implement 'let !p = ...', but I'm not certain. So, my question is whether this is intentional. If it is, then the bang patterns description should probably mention it, since it's subtly different than the rest of the specification. Also the warning should be removed, because there is no overlapping in the above case statement. If it is unintentional, we should probably decide either to make it intentional (and perform the above changes), or to change the implementation. :) Cheers, -- Dan

2 2