- Glasgow-haskell-users

testing 7.8.2
by Sergei Meshveliani 23 Apr '14

23 Apr '14

Dear GHC developers, I have tested ghc-7.8.2-src by making it by ghc-7.6.3 under Debian Linux. Then I have `made' my DoCon-2.12 application by ghc-7.8.2. It looks all right. For any occasion, here are some test results. Comparing it to ghc-7.4.1 shows the following. 1) The default context reduction stack (21) is not sufficient, so, I add -fcontext-stack=30 to the options. 2) The resulting libHSdocon-2.12.a is 1/10 larger (but the DoCon source is not the same, and it is, may be 1/100 larger). 3) The Main executable test size is almost the same. 4) The test running speed is the same. 5) The minimal -M memory setting for running the test is 4300 Kb against 2400 Kb of ghc-6.4.1. Regards, ------ Sergei

1 0

installing random-1.0.1.1
by Sergei Meshveliani 22 Apr '14

22 Apr '14

People, can you, please, explain me how to make the `random' package visible for GHC ? I have * installed haskell-platform-2013.2.0.0, * `made' ghc-7.8.2 from source by ghc-7.6.3, and run make configure under ghc-7.8.2 for my DoCon program. docon.cabal has ---------------------------------------- ... tested-with: GHC build-type: Simple build-depends: base >= 4 && < 5, containers >= 0.3 && <= 0.5.5.1, random >= 1.0 && < 1.2 . exposed-modules: ... extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts FlexibleInstances MultiParamTypeClasses OverlappingInstances RecordWildCards NamedFieldPuns DoAndIfThenElse ... ----------------------------------------- make configure reports runghc Setup.hs configure --ghc --prefix=/home/mechvel/docon/2.12/docon/source/inst -v Configuring docon-2.12... Setup.hs: At least the following dependencies are missing: random >=1.0 && <1.2 I do cabal install random, and now ghc-pkg list shows ------------------------------------- /home/mechvel/ghc/7.8.2/inst0/lib/ghc-7.8.2/package.conf.d Cabal-1.18.1.3 ... containers-0.5.5.1 ... ghc-7.8.2 ... unix-2.7.0.1 /home/mechvel/.ghc/x86_64-linux-7.8.2/package.conf.d random-1.0.1.1 -------------------------------------- But make configure still does not find random. The Haskell Platform is installed in the system area, ghc-7.8.2 and random-1.0.1.1 are installed in my home. Maybe, I need to run `register random' with some appropriate arguments? Can you, please, advise? Thanks, ------ Sergei

2 1

Tightening up on inferred type signatures
by Simon Peyton Jones 21 Apr '14

21 Apr '14

Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn't followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon

3 2

Concrete syntax for open type kind?
by Conal Elliott 21 Apr '14

21 Apr '14

I see ‘#’ for unlifted and ‘?’ for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind :: { IfaceKind } : akind { $1 } | akind '->' kind { ifaceArrow $1 $3 } However, I don’t know how to get GHC to accept ‘#’ or ‘?’ in a kind annotation. Are these kinds really available to source programs. I see that undefined has an open-kinded type: *Main> :i undefined undefined :: forall (a :: OpenKind). a -- Defined in ‘GHC.Err’ Looking in the GHC.Err source, I just see the following: undefined :: a undefined = error "Prelude.undefined" However, if I try similarly, q :: a q = error "q" I don’t see a similar type: *X> :i q q :: forall a. a -- Defined at ../test/X.hs:12:1 I don't know what kind 'a' has here, nor how to find out. -- Conal

3 6

Re: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
by Roman Cheplyaka 19 Apr '14

19 Apr '14

* M Farkas-Dyck <strake888(a)gmail.com> [2014-04-19 12:55:23-0500] > On 19/04/2014, Roman Cheplyaka <roma(a)ro-che.info> wrote: > > Don't know if it helps, but I think ghci loads the dynamic library, not the static one. > > I straced both the broken ghci on aforesaid system and a working ghci > on a glibc system and it loads bare .o files. Interesting. I thought that has changed in 7.8. I'd love to see an explanation from someone knowledgeable. Roman

1 0

Autocomplete command line options with GHC 7.8
by Jan Stolarek 16 Apr '14

16 Apr '14

Hi all, GHC 7.8 adds --show-options flag that prints all supported command line flags on standard output. This can be used to enable autocompletion of command line options for ghc in shells that support autocompletion. If you're using bash add this snippet to your ~/.bashrc file: <<<<<<<<<<<<< START # Autocomplete GHC commands _ghc() { local envs=`ghc --show-options` # get the word currently being completed local cur=${COMP_WORDS[$COMP_CWORD]} # the resulting completions should be put into this array COMPREPLY=( $( compgen -W "$envs" -- $cur ) ) } complete -F _ghc -o default ghc <<<<<<<<<<<< END Enjoy. Janek PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags Feel free to add instructions for other shells.

2 3

-optl behavior in ghc-7.8.1
by Yuras Shumovich 15 Apr '14

15 Apr '14

Hi, I found that -optl behavior was changed in ghc-7.8.1 ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite. $ /opt/ghc-7.6.3/bin/ghc --make main.hs -optl=hello -v ... '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'main' 'main.o' 'hello' ... ... $ /opt/ghc-7.8.1/bin/ghc --make main.hs -optl=hello -v ... /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE hello -o main main.o ... ... Is it intentional change? I want to compile in a number of static libraries. I have the next line in my cabal file: ld-options: ./path/to/libsomething.a It works ok on linux and mac os with ghc-7.6.3, but with ghc-7.8.1 I get undefined references for symbols from the libsomething.a Thanks, Yuras

4 10

Help with coercion & roles?
by Conal Elliott 14 Apr '14

14 Apr '14

I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) "tpl"#) `cast` (<LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) ∷ LambdaCCC.Lambda.EP (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin <LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal

3 7

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