- Glasgow-haskell-users

Recursive loop in context simplification with GHC 7.10.1
by Joe Hendrix 22 May '15

22 May '15

Hi, I’m trying to migrate some code that compiles under GHC 7.8.4 to GHC 7.10.1. It uses the comparison operator (<=) in TypeLits, and seems to get in a recursive loop when simplifying contexts. I’ve included part of the output from "-ddump-tc-trace” once it gets stuck in the loop below. I’d appreciate any help on understanding what is happening. If it’s useful I could try to extract a minimal example showing the error, but I thought I’d try to understand what’s happening first. Thanks, Joe === flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK Following filled tyvar s_aifJ[fuv:0] = 1 GHC.TypeLits.<=? n_abP7[sk] flattenTyVar1 n_abP7[sk] GHC.TypeLits.Nat flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK Following filled tyvar s_aifJ[fuv:0] = 1 GHC.TypeLits.<=? n_abP7[sk] flattenTyVar1 n_abP7[sk] GHC.TypeLits.Nat flatten/flat-cache hit GHC.TypeLits.<=? [1, n_abP7[sk]] s_aifJ[fuv:0] cobox_aifK

1 0

documentation links broken in 7.10.1
by Evan Laforge 21 May '15

21 May '15

It seems like haddock's index.html generation is broken in 7.10.1. Namely, it creates links to e.g. Codec-Binary-UTF8-Generic.html when it should be to utf8-string-1/html/Codec-Binary-UTF8-Generic.html This is haddock 2.16.0, which comes with the binary distribution for 7.10.1. I looked at https://github.com/haskell/haddock/issues but didn't see anything related to this, which makes me think it's just me. You'd think someone would notice if all documentation links were broken. Does anyone else see this?

2 2

overlapping instances 7.10.1
by Sergei Meshveliani 21 May '15

21 May '15

People, I wrote recently about finding places to set {-# OVERLAPPING #-} when porting an application from 7.8.2 to 7.10.1. I am doing this for porting docon-2.12 from 7.8.2 to 7.10.1. And ghc-7.10.1 indeed helped me to find several places to set this pragma (instead of using the total key -XOverlappingInstances). Finally, it has come to this module: --------------------------------------------- Preprocessing library docon-2.12.1... [48 of 86] Compiling ResRing__ ( ResRing__.hs, dist/build/ResRing__.o ) ResRing__.hs:183:31: Overlapping instances for Eq (Maybe PropValue) arising from a use of ‘/=’ Matching instances: instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Base’ instance (Residue r, Eq a) => Eq (r a) -- Defined in ‘ResEuc0_’ In the expression: lookup IsGxBasis ps /= Just Yes ... ---------------------------------------------- As before, I set instance {-# OVERLAPPING #-} (Residue r, Eq a) => Eq (r a) where ... in ResEuc0_.hs. But this does not help, the compiler continues with the same report. I see the difference to previous porting process in that one of the overlapping instances is of the GHC library, so that I cannot set the needed overlap pragma for it. On the other hand, ghc-7.8.2 compiled docon-2.12 successfully. What my be a way out? Thanks, ------ Sergei

2 1

OI in 7.10.1
by Sergei Meshveliani 21 May '15

21 May '15

Please, what is wrong here? --------------------------------------------------------------- module OI where class Foo a where foo :: a -> Bool instance Foo Bool where foo _ = True data C a = C a instance {-# OVERLAPPING #-} Foo a => Foo (C a) where foo (C a) = foo a instance {-# OVERLAPPING #-} Foo (C Bool) where foo _ = False --------------------------------------------------------------- By this I intended to test the overlapping instance control. I set the pragma as it is shown in the User guide. And ghc-7.10.1 -c -XFlexibleInstances OI.hs reports "Unrecognised pragma". Please, advise, ------ Sergei

1 1

overlapping instances in 7.10.1
by Sergei Meshveliani 20 May '15

20 May '15

Dear GHC developers, Please, test ghc-7.10.1 on making docon-2.12 http://www.botik.ru/pub/local/Mechveliani/docon/ and running its demotest/Main (see install.txt). docon-2.12 has been tested under ghc-7.8.2, and it has extensions: ... OverlappingInstances in docon.cabal. Making with ghc-7.10.1 issues a warning and advises to set the related pragma individually to each corresponding instance. (1) First, I ignored this warning, and surprisingly, the library has been made. In the build/ subdirectory there are .hi and .o files, and there have newly appeared the "dyn" files: Matr0_.dyn_hi Matr0_.dyn_o Matr0_.hi Matr0_.o ... (I do not know what does it mean "dyn"). Then, > make install reports runghc Setup.hs install --user Installing library in /home/mechvel/docon/2.12/docon/source/inst/lib/x86_64-linux-ghc-7.10.1/docon_99cUeE74HI58Sb9XilYAZ2 Registering docon-2.12.1... Instead of the .a file, ls shows there docon_99cUeE74HI58Sb9XilYAZ2 docon_JzkSttB1MsX3R5AQ1eIgvC Are these names intended? Then I command > cd demotest > ghc $doconCpOpt -O -rtsopts --make Main > ./Main It is built and runs. But breaks in the middle with a certain reasonable DoCon error message. The DoCon design is so that choosing a different instance among the overlapping ones may change the algorithm, and the computation cost, but still must produce the same result. It must -- unless DoCon has a bug in some of these instances. (2) All right, I need to set {-# OVERLAPPABLE #-} individually to each instance which may overlap with some other instance in DoCon. There is declared a great number of instances. And it occurs difficult for me to recall now: which instance does overlap with something and which does not (at least they all worked correct in ghc-7.8.2). Well, I can set {-# OVERLAPPABLE #-} to _each_ instance. But such a program does not look nice. And I would like to be more definite and to set {-# OVERLAPPING #-} to all appropriate places. Suppose that I forget that some instance overlaps with something and skipped this pragma. The above test shows that this can lead to a wrong program to run (is this feature intended?). And what will be the consequence if {-# OVERLAPPING #-} is set to an instance which does not overlap with anything? Can the compiler help to list the overlaps? Please, advise, ------ Sergei

2 2

Can GHCi inspect the state of running threads?
by Facundo Domínguez 20 May '15

20 May '15

Hello, I have a multi-threaded and interactive application that sometimes stops responding, and it would be helpful being able to inspect the state when it doesn't. I thought the GHCi debugger could be useful here, however I see no way to signal a thread and have GHCi show me its state. Here is an example GHCi session: $ cat t.hs import Control.Concurrent import Control.Exception import Control.Monad import System.IO spawnThread :: String -> IO ThreadId spawnThread label = forkIO $ flip finally (putStrLn $ "bye " ++ label) $ forM_ [0..] $ \i -> threadDelay 1000000 $ ghci-7.10.1 t.hs -fbreak-on-exception -v0 *Main> hSetBuffering stdout LineBuffering *Main> t0 <- spawnThread "t0" *Main> throwTo t0 (ErrorCall "end") *Main> It looks like I'm not getting the "bye t0" message when stopping the thread while using -fbreak-on-exception. Is the debugger supposed to be used like this? Otherwise, is there any way in which I could inspect the state of a running thread? Thanks, Facundo

1 1

making 7.10.1
by Sergei Meshveliani 20 May '15

20 May '15

People, I am trying to `make' ghc-7.10.1 from source by ghc-7.8.3 on Debian Linux. I command > ./configure --prefix=/home/mechvel/haskell/ghc/7.10.1/inst0 > make >& make.log The former command seems successful: ... #define HAVE_EVENTFD 1 #define CC_SUPPORTS_TLS 1 configure: exit 0 The latter command reports --------------------------------------- ... ... checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/home/mechvel/haskell/ghc/7.10.1/libffi/build/x86_64-unkn\ own-linux-gnu': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details --------------------------------------- And I do not find in config.log anything suspicious about cpp. config.log does have several `error' messages, like, say conftest.c:9:28: error: ac_nonexistent.h: No such file or directory But, probably, they are harmless. Please, how to fix? ------ Sergei

2 2

Fedora ghc-7.10.1 repo
by Jens Petersen 13 May '15

13 May '15

Hi, It is a bit later than I wanted but I have prepared a Fedora Copr repo for ghc-7.10.1. https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.1/ (note the EPEL7 and F20 builds are currently quick builds and the F21+ builds are perf builds) I will probably add a cabal-install build soon. Let me know if you find any problems or if it is useful. :) Jens

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Dan Doel 11 May '15

11 May '15

vector generates a considerable amount of code using CPP macros. And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written). On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > > Perhaps it makes sense to scan hackage to find all the different CPP > idioms > > that are actually used in Haskell code, if it is a small/well-defined set > > it may be worth writing a simple custom preprocessor. > > > > +1, I'll wager that the vast majority of usages are just for version > range checks. > > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

5 5

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm

7 9