February 2015 - ghc-devs

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

arc land changes author
by Joachim Breitner 19 Dec '15

19 Dec '15

Hi, I was just about to apply a DR by David. First I ran $ arc patch D390 which put me on a feature branch. Then I reworded the commit with $ git commit --amend and then I tried to land it with $ arc land Luckily I also passed --hold... It even asked me if I want to land the commit although I am not the author: This branch has revision 'D390: Reorder GHC.List; fix performance regressions' but you are not the author. Land this revision by dfeuer? [y/N] y But it still put me in the author field: $ git show HEAD commit a387c359b99667ce55016de3816b5d9873a155db Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Wed Oct 29 08:17:05 2014 +0100 Reorder GHC.List; fix performance regressions Summary: Rearrange some oddly placed code. (and undid my commit message changes....) Did I do something wrong? Anyways, it said something along the lines of Cleaning up feature branch... (Use `git checkout -b 'arcpatch-D390' 'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it back.) so with $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029 I was able to get the edited commit message with the right author back. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

Right way to turn off dynamic linking in build.mk
by Johan Tibell 07 Jul '15

07 Jul '15

Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont "take". There's also this one: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan

4 5

stack traces when debugging GHC
by Richard Eisenberg 14 Apr '15

14 Apr '15

Hi devs, I've just made a miraculous discovery and I want to share! It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I'd love to put this on the wiki. Any clue where this might be found? Richard

5 5

Automating GHC build for Windows
by Roman Kuznetsov 29 Mar '15

29 Mar '15

Hello *, As I am still new in this, I will ask. Were there any attempt to automate GHC build process on Windows with some kind of CI engine, like Hudson, Jenkins, etc.? It seems to be rather helpful to publish build results if not after each commit, but at least once every day. WDYT? -- Sincerely yours, Roman Kuznetsov

7 16

MAC builds of 7.8.4 and 7.10.1 RC2
by Mark Lentczner 16 Mar '15

16 Mar '15

I have built "in the official manner" both GHC 7.8.4 and GHC 7.10.1 rc2 from sources. You can find them here: http://www.ozonehouse.com/mark/platform/ They need some "doesn't crash out of the box" testing on a few OS X systems before I think we should declare them good and put them on the download page. Can you help out? Basic instructions to install a bindist in a local, isolated area (so you don't clobber your system GHC installation): mkdir test-ghc cd test-ghc tar xf $binddist_tar_file cd ghc* configure --prefix=`cd ..; pwd` make install cd .. Let me know if that works - and what version of OS X you used. - Mark

7 8

Porting to Haiku
by Jessica Hamilton 11 Mar '15

11 Mar '15

Hi, I (and one other) am working on porting GHC to Haiku; we've successfully got a working GHC cross-compiler running on Haiku, and now are able to also build GHC on Haiku from the cross-compiler when using the "quickest" profile in the mk/build.mk file. However, using the default build profile, we're running into a couple of issues. 1. A random segfault in ghc-stage1 (is probably an issue in Haiku, not entirely sure yet), with the following call stack: runCFinalizers + 0x3a runAllCFinalizers + 0x37 hs_exit_ +0x99 shutdownHaskellAndExit + 0x2f hs_main + 0xb1 .../ghc-7.8.3/inplace/lib/bin/ghc-stage1 + 0xc7b374 _start + 0x4b runtime_loader + 0x130 I can't really see anything obvious in the source code myself (although our debugger fails to enumerate the semaphores, and also needs to be killed). Restarting the build is sufficient to get past the issue, however. 2. A more pressing issue is with ghc-cabal. It fails with the error "resource exhausted" when running the following command: inplace/bin/ghc-cabal copy compiler stage2 This error is reproducible every time. I've tried setting up a profile build in the mk/build.mk file in order to get a stack trace from ghc-cabal; however, after rebuilding GHC from scratch, running ghc-cabal +RTS -xc, it still complains that the flag -xc requires the program to be built with -prof. Some advice would be handy before diving into another couple hours of rebuilding GHC to try and get a profiled build of ghc-cabal out of the build system ;-) Cheers, Jessica

2 1

Fwd: EvTerms and how they are used
by Jan Bracker 02 Mar '15

02 Mar '15

Hi Adam, thank you for your quick and detailed answer! I think I understand how to construct evidence for typeclass constraints now. But trying to apply this, I still have some problems. I have something along the following lines: class Polymonad m n p where -- Functions instance Polymonad Identity Identity Identity where -- Implementation -- Further instances and some small chunk of code involving them: The code implies the following constraint: Polymonad Identity n_abpq Identity As the ambiguity error I get says, when trying to compile this: There is only one matching instance (the one above, lets call it $fPolymonadIdentityIdentityIdentity). So my plugin tries to tell GHC to use that instance. As far as I understand it, since the parameters of $fPolymonadIdentityIdentityIdentity are no type variables and there is no superclass it should be as easy as saying: EvDFunApp $fPolymonadIdentityIdentityIdentity [] [] But when I run this with -dcore-lint I get the following error message: *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: Warning: In the expression: >> @ Identity @ Any @ Identity $fPolymonadIdentityIdentityIdentity @ () @ () (idOp @ Bool True) (>>= @ Identity @ Identity @ Any $fPolymonadIdentityIdentityIdentity @ Char @ () (return @ Char @ Identity $fPolymonadIdentityIdentityIdentity (C# 'a')) (\ _ [Occ=Dead] -> return @ () @ Identity $fPolymonadIdentityIdentityIdentity ())) Argument value doesn't match argument type: Fun type: Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk] Arg type: Polymonad Identity Identity Identity Arg: $fPolymonadIdentityIdentityIdentity What am I missing? Why doesn't the argument type "Polymonad Identity Identity Identity" match the first argument of the function type "Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk]". Why is the type variable translated to "Any"? Best, Jan 2015-02-25 13:35 GMT+00:00 Adam Gundry <adam(a)well-typed.com>: > Hi Jan, > > Yes, unfortunately the meaning of EvTerm is a weak point of the current > typechecker plugins story; it rather requires one to understand how > GHC's constraint solver produces evidence. There are lots of papers on > evidence for equality constraints in System FC, but typeclass > constraints are generally ignored as they are just datatypes at the FC > level. > > Let me try to give you some idea of what EvDFunApp means, then hopefully > those with more knowledge of the GHC internals can correct me... > > If you write a class instance, e.g. > > instance (Show a, Show b) => Show (T a b) where ... > > then GHC generates a dfun (short for "dictionary function", I guess) > > $fShowT :: forall a b . (Show a, Show b) => Show (T a b) > > where Show is treated as a record data type containing a dictionary of > methods for the class. At the core level, this is a normal term-level > function (albeit with a strange name). > > Now when the typechecker has a constraint to solve, say > > Show (T Int Bool), > > it produces evidence for this by applying $fShowT to the appropriate > types and to evidence for the superclass constraints, in this case > something like > > $fShowT @Int @Bool $fShowInt $fShowBool > > where I'm using @ for type application. This is represented in EvTerm as > > EvDFunApp $fShowT [Int, Bool] [ EvDFunApp $fShowInt [] [] > , EvDFunApp $fShowBool [] [] ] > > Thus the [Type] is the list of kinds/types at which to instantiate the > dfun, and the [EvTerm] is the list of evidence terms to which it must be > applied. Obviously this application should be well-typed, and > -dcore-lint will complain if it is not. > > For typechecker plugins, it would be nice if we could write arbitrary > core expressions as evidence, but this hasn't yet been implemented > (partially because most of the examples so far solve equality > constraints, rather than typeclass constraints). > > Hope this helps, > > Adam > > > On 25/02/15 10:55, Jan Bracker wrote: > > Hello, > > > > I am trying to use the new type checker plugins [1] that are implemented > > in head. > > > > When successful a plugin has to return a [(EvTerm, Ct)] for the solved > > constraints. The documentation on EvTerms is scarce [2,3,4] and I could > > not find papers that explain them (many talk about 'evidence', but they > > never get concrete). > > > > So far I have figured out that "EvDFunApp DFunId [Type] [EvTerm]" > > selects a certain instance to be used for a constraint, though I don't > > know what the list of EvTerms in the end is for. I am also a bit unclear > > on how the "[Type]" is used.If I turn on '-dcore-lint' I get errors. So > > I still seem to be using it wrong. > > > > I have also asked in IRC, but did not get a response to my question. > > > > I am sorry if this is the wrong mailing list to ask. If there is a more > > apropriate place just point it out. > > > > Best, > > Jan > > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > [2]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… > > [3]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… > > [4]: > http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/users_guide/comp… > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ >

3 3

GHC with cabal-install
by Kazu Yamamoto 26 Feb '15

26 Feb '15

Hello, To my experience, it is easy to install GHC to Linux such as CentOS. But it is hard to install cabal-install after that. Are there any reasons to not include cabal-install in GHC binary packages? GHC provides Cabal library. Why not cabal-install? --Kazu

3 5

RE: The suggested redundant import solution doesn't work for explicit import lists
by Simon Peyton Jones 26 Feb '15

26 Feb '15

OK. I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/10117 In fact there is a pretty good specification here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/UnusedImports So back to you: based on the existing, can you think of a variant that would work better? Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 February 2015 12:00 | To: Simon Peyton Jones | Cc: Herbert Valerio Riedel; Johan Tibell; Edward Kmett; Austin Seipp | Subject: Re: The suggested redundant import solution doesn't work for | explicit import lists | | Simon, | | The problem: | | trying to avoid redundant-import warnings due symbols having moved to | 'Prelude' due to AMP/FTP w/o CPP usage | | e.g. | | import Control.Applicative (Applicative) | | foo :: Applicative f => ... | foo = ... | | now warns that 'Applicative' is redundant, as it's exported from | 'Prelude' now. 'Monoid' is another such example that's now re-exported | from 'Prelude' (but wasn't before GHC 7.10). | | | One thing that happens to work is the trick shown at | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f...isredundant | i.e. | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid | import Data.Word | import Prelude | | as in that case, 'Prelude' is explicitly imported last, and so GHC | doesn't warn about Data.{Word,Monoid} being redundant (due to the way | the redundancy-check is implemented in GHC) | | However, if the example above is rewritten as | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid (Monoid(..)) | import Data.Word (Word) | import Prelude | | GHC would warn, as it handles import-listed symbols differently than | wildcard imports... | | and the question is, whether we can easily get the latter example to | become warning free as well w/o risking breakages elsewhere... | | ...is it clearer now what I'm suggesting? | | Cheers, | hvr | | On 2015-02-24 at 12:50:35 +0100, Simon Peyton Jones wrote: | > I'm sorry, but can someone re-articulate the question? I'm deep | underwater, so reluctant to reverse-engineer the question from the | thread. | > I think you are asking for some feature. But I'm not sure what the | spec is. | > | > Simon | > | > | -----Original Message----- | > | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | > | Sent: 24 February 2015 11:29 | > | To: Johan Tibell | > | Cc: Edward Kmett; Simon Peyton Jones; Austin Seipp | > | Subject: Re: The suggested redundant import solution doesn't work | > | for explicit import lists | > | | > | Johan, | > | | > | You're right, I'm afraid the Prelude-trick doesn't work well with | > | import-lists... not sure though if it's worth the risk to tweak | GHC | > | 7.10.1's redundant-warning detection to make it work here too... | > | | > | @SPJ, any comments? | > | | > | for more context: | > | | > | - | > | | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f.. | > | .isredundant | > | - | > | | http://www.reddit.com/r/haskell/comments/2wx64g/ghc_710_will_use_pla | > | n_ftp | > | /covdas0 | > | | > | Cheers, | > | hvr | > | | > | On 2015-02-24 at 11:47:30 +0100, Johan Tibell wrote: | > | > The suggested fix for unused imports resulting from the move of | e.g. | > | > Data.Monoid doesn't work when using explicit import lists: | > | > | > | > $ cat Test.hs | > | > module Test where | > | > | > | > import Data.Monoid (Monoid) | > | > import Prelude | > | > | > | > f :: Monoid a => a | > | > f = undefined | > | > $ ghc-7.10.0.20150123 -Wall /tmp/Test.hs | > | > [1 of 1] Compiling Test ( /tmp/Test.hs, /tmp/Test.o | ) | > | > | > | > /tmp/Test.hs:3:1: Warning: | > | > The import of ‘Data.Monoid’ is redundant | > | > except perhaps to import instances from ‘Data.Monoid’ | > | > To import instances alone, use: import Data.Monoid() | > | > | > | > It does work if you don't have an import list (bad idea) or use | > | qualified | > | > imports (good idea). | > | > | > | > -- Johan | > | | > | -- | > | "Elegance is not optional" -- Richard O'Keefe | | -- | "Elegance is not optional" -- Richard O'Keefe

2 1