September 2014 - ghc-devs

HEADS UP: Running cabal install with the latest GHC
by Edward Z. Yang 27 Sep '14

27 Sep '14

Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in HEAD. So, how do you get a version of cabal-install (and Cabal) which is new enough to do what you need it to? The trick is to compile Cabal using your /old/ GHC. Step-by-step, this involves cd'ing into libraries/Cabal/Cabal and running `cabal install` (or install it in a sandbox, if you like) and then cd'ing to libraries/Cabal/cabal-install and cabal install'ing that. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward

5 8

Re: Permitting trailing commas for record syntax ADT declarations
by Alexander Berntsen 26 Sep '14

26 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forwarding this & my reply to the ML as well, On 22/09/14 14:27, David Luposchainsky wrote: > +1. While you're at it, you may also want to consider allowing > leading commas for the folks that write their exports/records "the > other way round" Sure. Both styles are common in the wild, so that makes sense. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgFo4ACgkQRtClrXBQc7Xz1QEAn5rLEoUuHPGRkJIEy/ZKHuiM xxIF+i/E8X1Y5cdd5HQA/jski9JOlu7LdY1ieucpSMe2KgF3v0VHO+aO+q7QZ93x =v9Ba -----END PGP SIGNATURE-----

13 44

REMINDER: Please review the HCAR entry for GHC!
by Austin Seipp 26 Sep '14

26 Sep '14

Hi *, Just a regularly scheduled reminder: please double-check the latest HCAR entry so we can make sure it's great for the October edition: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 The current page looks good, but we're missing some things like: - Backpack updates - Information on the BBP from Herbert. - We've implemented some new optimizations since last time, like Call Arity, and some other improvements. - Other things: AArch64 support, probably other stuff. I'm sure you all remember what you did. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Linux failures
by Simon Peyton Jones 26 Sep '14

26 Sep '14

I am getting one persistent failure on Linux: =====> user001(normal) 5 of 29 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd . && ./user001 >user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) This is in libraries/unix/tests. I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 @@ -0,0 +1 @@ +ghc-stage2: ioManagerWakeup: write: Bad file descriptor I don't think these can be caused by my commits, but they should be fixed.... Any offers? Simon

4 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 26 Sep '14

26 Sep '14

I am trying to avoid having a type parameter for DynFlags, and so far the only thing that needs it is the hooks. I am currently working it through without hooks in DynFlags, and when I have something concrete I will ask againfor suggestions. I just wanted an initial test of the waters to make sure there was no a priori reason not to do it. On Fri, Sep 26, 2014 at 10:09 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.8.3 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > You'll need to be much more explicit before anyone is likely to venture an > opinion. What is the impact of "managed separately"? What is the > motivation for making a change at all? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:10> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

GHC AST Annotations
by Alan & Kim Zimmerman 26 Sep '14

26 Sep '14

Now that the landmines have hopefully been cleared from the AST via [1] I would like to propose changing the location information in the AST. Right now the locations of syntactic markers such as do/let/where/in/of in the source are discarded from the AST, although they are retained in the rich token stream. The haskell-src-exts package deals with this by means of using the SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC Located type but also has a list of SrcSpan s for the syntactic markers, depending on the particular AST fragment being annotated. In addition, the annotation type is provided as a parameter to the AST, so that it can be changed as required, see [3]. The motivation for this change is then 1. Simplify the roundtripping and modification of source by explicitly capturing the missing location information for the syntactic markers. 2. Allow the annotation to be a parameter so that it can be replaced with a different one in tools, for example HaRe would include the tokens for the AST fragment leaves. 3. Aim for some level compatibility with haskell-src-exts so that tools developed for it could be easily ported to GHC, for example exactprint [4]. I would like feedback as to whether this would be acceptable, or if the same goals should be achieved a different way. Regards Alan [1] https://phabricator.haskell.org/D157 [2] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… [3] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… [4] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-…

5 10

How to build the user guide?
by Jan Stolarek 25 Sep '14

25 Sep '14

Is there a way to build the user guide without having to build everything? The wiki [1] suggests cd docs/users_guide make html stage=0 FAST=YES but that doesn't seem to work. Janek [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Docs

2 1

Re: ghc-devs Digest, Vol 133, Issue 40
by David Feuer 24 Sep '14

24 Sep '14

Simon Peyton Jones wrote: > anywhere, I think. You might want a new HsSyn data type for "list with > possible leading or trailing commas": > > data HsCommadList a > = HCL > Int -- Number of leading commas > [a] > Int -- Number of trailing commas > If we're going to go to the trouble of supporting extra leading and trailing commas, why not also support extra commas in the middle? That way, #include "theseexports" , #include "thoseexports" doesn't have to worry about how these and those exports are listed. David

2 1

Re: FoldrW/buildW issues
by David Feuer 24 Sep '14

24 Sep '14

On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> wrote: > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. One nice thing about this idea (which sounds like it must be related to the "state hack", but is more explicit) is that it presumably applies also to similar situations in the State and ST monads, when a state transformer is only used once. Could you explain, perhaps, what compiler transformation this enables, and how you implemented it? It would be nice if the compiler could figure this out for itself, but I'm sure that's much too big a project for 7.10, whereas making sure foldl, scanl, mapAccumL, foldM, sum, etc., work really reliably seems important. And yes, I do think such a thing would probably work for scanl and such, assuming GHC's analysis can use the information properly—they're just state-transforming list producers. David

2 1

Re: Building ghc on Windows with msys2
by Thomas Miedema 24 Sep '14

24 Sep '14

Hello msys2 users, I came across ticket #8842 <https://ghc.haskell.org/trac/ghc/ticket/8842>: "Make sure msys2 builds non emulating binaries". Maybe it is of interest to you, it mentions something about emulation functions being really slow. Please close it if it is not relevant. Cheers, Thomas On Mon, Sep 15, 2014 at 11:33 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Thank you! Indeed Neil Mitchell is also acting as “guinea pig” at the > moment. It would be **great** if together you were able to clean up the > “how to build on Windows” page, remove out of date or misleading > information, and yes I think we should focus on msys2. > > > > Great stuff > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Gintautas > Miliauskas > *Sent:* 15 September 2014 21:58 > *To:* ghc-devs(a)haskell.org > *Subject:* Building ghc on Windows with msys2 > > > > Hello, > > > > I have been messing around a little bit with building GHC from source on > Windows, and found the msys2 wikipage > <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2> quite > useful, but somewhat outdated. Quite a few steps in those instructions are > no longer necessary and can be omitted. I am working on cleaning up that > wikipage right now and should be done in a day or two. > > > > I've found a recent email > <http://www.haskell.org/pipermail/ghc-devs/2014-September/006251.html> in > the middle of updating the wikipage about other people planning to do the > same, so I thought I'd shoot an email to make sure that work is not being > duplicated. > > > > msys2 seems to be in good shape and should probably be promoted to the > primary suggested method to build ghc on Windows. Let's look into that once > the new build instructions have been proofread and verified. > > > > Best regards, > > -- > Gintautas Miliauskas > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

1 0