April 2015 - ghc-devs

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

13 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

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

11 21

Backporting srcLoc to the GHC 7.10 branch
by Michael Snoyman 15 Jul '15

15 Jul '15

It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049

9 20

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

MSYS2 package for GHC 7.10.1
by David Macek 05 Jun '15

05 Jun '15

Hi everyone. After finally putting some uninterruped effort into it, I managed to create (hopefully) working prototypes of two GHC-related packages for MSYS2, namely ghc[1] and cabal-install[2]. I've prepared recipes (PKGBUILDs) for building from source, but 64-bit binaries[5][6] are also provided for those who'd like to test my build without building it themselves. With this post, I'd like to start some work towards the following goals (I hope we can get some Windows discussion going again): - verify that the build is reproducible (see below for instructions) - make tests pass - fix known issues (see below for list) - discover and fix unknown issues - review and upstream as many patches as possible - make it easier for people on Windows to start hacking on GHC I'll be glad to read any responses, notes, results, hints, comments and/or criticisms. Please note that I'm writing this after being submerged in the matter for some time, so don't be surprised to see any glaring omissions or obvious mistakes. Known issues ============ Configure has a problem with docbook - This mean Haddock is not built. It's probably some silliness on the part of MSYS2's docbook. Integer-gmp object file has a reference to __mingw_vsnprintf - Compiling seems to work fine, presumably because the final link command includes -lmingwex, but `runhaskell Setup.lhs` in the text package source tree gave me an undefined reference error, causing inability to load integer-gmp module. I don't know where to start fixing this, as I have not yet reached the depth of understanding of GHC source needed for that. Wildly untested - I didn't try building with LLVM and the testsuite is currently failing to start, giving some weird errors. Trying cross compiling or compiling a cross compiler didn't even cross my mind (har har). Patches ======= A lot of the patches deal with the directory structure -- I tried to mirror the common FHS layout as closely as possible while still retaining the advantages of relocatability. I also removed the bundled toolchain and perl, in favor of packages included with MSYS2. I assume these changes are somewhat controversial for upstreaming, but it'd be nice to see the official bindists to adopt this layout. There are several patches that I think are more of straight-forward fixes rather than design changes, namely numbers 0007, 0010, 0014 and 0015. Build instructions ================== General build instructions[3] are available at our wiki. For convenience, I've compiled a sequence of commands that should get you the ghc and cabal-install packages, given that you start with an up-to-date installation of MSYS2 and a working GHC in PATH. Refer to our guide[4] for correct way of getting/upgrading your MSYS2. ## start MSYS2 shell pacman --needed -S base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain git clone https://github.com/elieux/mingw-packages cd mingw-packages git checkout ghc pushd mingw-w64-ghc makepkg-mingw -sLf pacman -U mingw-w64-*-ghc-*-any.pkg.tar.xz ## remove old GHC from PATH popd pushd mingw-w64-cabal-install makepkg-mingw -sLf pacman -U mingw-w64-*-cabal-install-*-any.pkg.tar.xz popd If you prefer to build only for one architecture, export a variable named MINGW_INSTALLS with a value of "mingw32" or "mingw64" before building. == [1] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-ghc [2] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-cabal-install [3] http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-cabal-install… [6] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-ghc-7.10.1-1-… -- David Macek

3 5

RE: Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 01 May '15

01 May '15

There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 about whether the new Coercible story makes GND ok for Safe Haskell. At a type-soundness level, definitely yes. But there are other less-clear-cut issues like “breaking abstractions” to consider. The decision on the ticket (comment:36) seems to be: GND stays out of Safe Haskell for now, but there is room for a better proposal. I don’t have an opinion myself. David Terei and David Mazieres are in the driving seat, but I’m sure they’ll be responsive to user input. However, I think the user manual may not have kept up with #8827. The sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.” vanished from the 7.8 user manual (links below). Maybe it should be restored. Safe Haskell aficionados, would you like to offer a patch for the manual? And maybe also a less drastic remedy than omitting GND altogether? Simon From: Omari Norman [mailto:omari@smileystation.com] Sent: 09 April 2015 02:44 To: haskell Cafe Subject: Generalized Newtype Deriving not allowed in Safe Haskell When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe flag, I get -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell This happens both in GHC 7.8 and GHC 7.10. I thought I remembered reading somewhere that GNTD is now part of the safe language? The GHC manual used to state that GNTD is not allowed in Safe Haskell: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… But this language on GNTD not being part of the safe language was removed in the 7.8 manual: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… The GHC release notes don't say anything about this one way or the other. Thoughts?

3 9

Roles, GND, Data.Coerce
by David Terei 01 May '15

01 May '15

All, An issue that came up with GHC 7.8 was the design of Roles and Data.Coerce, with it's ability to break module abstractions by default, requiring programmers adopt explicit role annotations to enforce some types of invariants for abstract data types. Because of this issue, as of now, GND & Data.Coerce are still disabled in Safe Haskell. We'd like to change this but need feedback from everyone. I've written up a wiki page with lots of information on the issue: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles Please read, it has information on how Roles work, the problem it raises and subtleties in the current system. Possible paths forward are also there, but I'll include below. Please be aware that this discussion is about Roles in general, not specifically how when using -XSafe. Ideally we'd come up with a solution that works regardless of if using Safe Haskell or not. I personally like option (3), although it isn't clear to me how hairy the implementation would be. == Possible Paths Forward for Roles == 1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell. 2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe in Safe Haskell and warn users that they neednominal role annotations on ADTs. 3) In-scope constructor restriction for lifting instances -- The newtype constructor restriction for unwrapping instances could be extended to both data types, and the lifting instances of Data.Coerce. This is, GND & Coercing under a type constructor is allowed if (a) all involved constructors are in scope, or (b) the constructors involved have been explicitly declared to allow coercion without them being in scope. I.e., (b) allows library authors to opt-into the current GHC behavior. This would require new syntax, probably just an explicit deriving Coercible statement. 4) Change default role to nominal -- This will prioritize safety over GND, and the belief is that it may break a lot of code. Worse, that it will be an ongoing tax as role annotations will be needed to enable GND. 5) Nominal default when constructors aren't exported -- When a module doesn't export all the constructors of a data type, then the type parameters of the data type should default to nominal. This heuristic seems to capture somewhat the intention of the user, but given the practice of defining an Internal module that exports everything, it seems of limited use. 6) Nominal default in future -- Add a new extension, SafeNewtypeDeriving that switches the default role to nominal, but continue to provide a deprecated GND extension to help with the transition. The claims in support of representational roles as default though believe that nominal by default has an ongoing, continuous tax, not just a transition cost. So it isn't clear that any scheme like this satisfies that argument. 7) Safe Haskell Specific -- Many of the above approaches could be adopted in a Safe Haskell specific manner. This isn't ideal as it makes safe-inference harder and Safe Haskell less likely to remain viable going forward. Richard suggests one such idea. == The belief by many people seems to be that (4) and (6) would be too much of burden. I'd like to avoid (7) if possible. It isn't clear to me if (7) ends up better than (2). I'm going to try to setup some infastructure for compiling Hackage so that we can measure how impactful these changes would be. Cheers, David

1 0

RE: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr from local calls
by Simon Peyton Jones 30 Apr '15

30 Apr '15

Thanks! I've added a comment to the relevant Note to document the effect. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 30 April 2015 08:10 | To: Simon Peyton Jones | Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr | from local calls | | nomeata added a subscriber: nomeata. | nomeata added a comment. | | Nice: -4% alloc in nofib/multiplier, -2.8% in nofib/minimax. 👍 | | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb61562feb876 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC | Cc: nomeata

1 0

Fixing anchors in GHC docs
by Eric Crockett 28 Apr '15

28 Apr '15

I think I sent this out already, but never heard back. An issue was fixed in HsColour regarding HTML anchors in the GHC docs, documented here: https://github.com/haskell/hackage-server/issues/319 Apparently GHC devs upload their own documentation [to hackage], which means HsColour needs to be updated on your end so that anchors are correct the next time docs are generated. -Eric

1 0