May 2015 - Glasgow-haskell-users

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 12 May '15

12 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

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

08 May '15

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by wren romano 07 May '15

07 May '15

On Wed, May 6, 2015 at 9:05 AM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> 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. Conditional imports are far and away the most commonly used idiom. Second most common, I'd say, is specifying GHC-specific vs compiler-generic implementations of top-level functions (e.g., using GHC.Exts.build or not). For both of these it's sufficient to have the #if construction plus everything needed for the conditional expressions. However, while the #if construction covers the vast majority of use cases, it doesn't cover all of them. Macros are also important. For example, a number of low-level libraries will use macros for things like having assertions which are either compiled as runtime checks, or as nothing, depending on a Cabal flag. Of course, there are plenty of other places where we want to use macros in low-level code, either to force inlining, or to have conditional compilation of (non-top-level) expressions that show up over and over. That these idioms aren't more common is just because there aren't more people working on such low-level code. In theory TH should be able to handle this stuff, but TH is a verbose sledgehammer for these sorts of problems, and using TH means restricting yourself to being GHC-only. -- Live well, ~wren

1 0

Re: RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 07 May '15

07 May '15

On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Assuming this was a serious suggestion, the benefit is that you could clearly mark what CPP you want to develop against, but OTOH, we'd lose backward compat w/ Haskell compilers only knowing about the old -XCPP but not the other new variants of the language-pragma. Moreover, there can now be packages that require clang-cpp, while others require gcc-cpp, and I don't think it can be assumed that both are available on every GHC installation. So it could cause packages to fail compiling simply because the respective CPP-flavor is missing. On the bright side, this would maybe give us the opportunity to coin the new term "CPP Hell" =) Cheers, hvr

1 0