May 2014 - ghc-devs - Haskell.org

cgrun051
by Simon Peyton Jones 10 May '14

10 May '14

I'm getting Unexpected failures: . cgrun051 [bad exit code] (normal,hpc,optasm,profasm,ghci,threaded1,threaded2,dyn,profthreaded,optllvm,g1) =====> cgrun051(optasm) 46 of 98 [0, 2, 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 cgrun051 cgrun051.hs -O -fasm >cgrun051.comp.stderr 2>&1 cd . && ./cgrun051 </dev/null >cgrun051.run.stdout 2>cgrun051.run.stderr Wrong exit code (expected 0 , actual 1 ) cgrun051 throws an exception, so presumably should have exit code 1. And it does. But the test seems to test for exit code 0. Why does the test check for 0 not 1? And what has changed? This is HEAD. I don't have a virgin head right now, but I don't think any of my changes could cause this. I am also seeing the ffi/should_compile cc004 [stderr mismatch] (normal) errors that Joachim reported. It'd be great if someone could fix that, whatever it is. SImon

3 2

GHC status report
by Simon Peyton Jones 09 May '14

09 May '14

As Austin has told us, there's a draft of the GHC Status Report for the HCAR, here: https://ghc.haskell.org/trac/ghc/wiki/Status/May14 Have we missed out something you have been working hard on? Do take a moment to add a bullet in an appropriate place (it's a wiki). I'd like to be sure that we are giving credit to all the appropriate people, so please help us fix that too. GHC is a team effort. Deadline is 1 May I think. Thanks Simon

10 40

GHC not parsing TH pretty printed code
by George Roldugin 09 May '14

09 May '14

Hi all, I've hit a problem with GHC 7.8 where the code pretty printed by Template Haskell fails to parse. The problem is with the placement of explicit semicolons in place of indentation. The following code pretty printed by TH won't parse: bar = do {let x = 5; return x} GHC expects the following placement of semicolons: bar = do {let x = 5 ; return x} I reported this bug and included sample TH code to reproduce the problem here: https://ghc.haskell.org/trac/ghc/ticket/9022 I rely on compiling code constructed with TH for my thesis project. Is there a work around I could use besides going back to GHC 7.6? Cheers, George

3 2

Simplifying casts and beta-reduction
by Conal Elliott 09 May '14

09 May '14

I'm looking for tools to help simplify Core terms that involve casts. In particular, I want to beta-reduce when the function is wrapped with a cast. Do the GHC sources have such utility functions? Here is an example of a lambda expression with a cast. In context, it's applied to two type arguments and two dictionary arguments and returns a function of one more argument. (The function `(-->)` is defined as `(f --> h) g = h . g . f`.) > ((\ (@ a8) (@ b) > ($dEncodable :: Encodable a8) > ($dEncodable1 :: Encodable b) -> > case $dEncodable of _ > D:Encodable _ tpl_B3 -> > case $dEncodable1 of _ > D:Encodable tpl_B2 _ -> > \ (g :: a8 -> b) (eta :: Encode a8) -> tpl_B2 (g (tpl_B3 eta)) > ) > `cast` (forall a8 b. > <Encodable a8>_R > -> <Encodable b>_R > -> <a8 -> b>_R > -> Sub (Sym (TFCo:R:Encode(->)[0] <a8>_N <b>_N)) > :: (forall a8 b. (Encodable a8, Encodable b) => > (a8 -> b) -> Encode a8 -> Encode b) > ~# > (forall a8 b. (Encodable a8, Encodable b) => > (a8 -> b) -> Encode (a8 -> b)))) I can imagine pushing the `cast` down through the type lambdas while stripping off `forall` coercions, then pushing the remaining `cast` through the dictionary arguments, while stripping off the outer `<Encodable t>_R ->` coercion wrappers, and then pushing the cast into the `case` alternatives and the lambda body, leaving something like > (\ (@ a8) (@ b) > ($dEncodable :: Encodable a8) > ($dEncodable1 :: Encodable b) -> > case $dEncodable of _ > D:Encodable _ tpl_B3 -> > case $dEncodable1 of _ > D:Encodable tpl_B2 _ -> > \ (g :: a8 -> b) -> > (\ (eta :: Encode a8) -> tpl_B2 (g (tpl_B3 eta))) > `cast` (Sub (Sym (TFCo:R:Encode(->)[0] <a8>_N <b>_N)) > :: (Encode a8 -> Encode b) > ~# > (Encode (a8 -> b)))) Now, given type, dictionary, and function arguments, I think we could beta-reduce. Before I try implementing these transformations, does something like them already exist in GHC? Thanks, -- Conal

3 8

Cabal can't open a TCP connection
by Simon Peyton Jones 09 May '14

09 May '14

Dear ghc-devs Cabal can't open a TCP connection from my Linux box. It used to work fine. Here's what it says: cabal -v3 update Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/1.16.0.2 Host: hackage.haskell.org proxy uri host: , port: Creating new connection to cabal: openTCPConnection: host lookup failure for "" simonpj@cam-05-unx:~/code/HEAD$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library simonpj@cam-05-unx:~/code/HEAD$ Can anyone help me work out what to do? git works just fine, so the internet is connected all right. Thanks Simon

4 5

SV: Cabal can't open a TCP connection
by Niklas Larsson 08 May '14

08 May '14

Looks like your proxy configuration is wrong. Git has its own proxy settings in .gitconfig. Look at the http_proxy environment variable. If you're not actually behind a proxy the problem could be the existence of http_proxy or HTTP_PROXY. ----- Ursprungligt meddelande ----- Från: "Simon Peyton Jones" <simonpj(a)microsoft.com> Skickat: ‎2014-‎05-‎08 14:04 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Kopia: "Simon Marlow" <marlowsd(a)gmail.com> Ämne: Cabal can't open a TCP connection Dear ghc-devs Cabal can’t open a TCP connection from my Linux box. It used to work fine. Here’s what it says: cabal -v3 update Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 User-Agent: cabal-install/1.16.0.2 Host: hackage.haskell.org proxy uri host: , port: Creating new connection to cabal: openTCPConnection: host lookup failure for "" simonpj@cam-05-unx:~/code/HEAD$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library simonpj@cam-05-unx:~/code/HEAD$ Can anyone help me work out what to do? git works just fine, so the internet is connected all right. Thanks Simon

1 0

Automating Windows setup for development
by Niklas Larsson 07 May '14

07 May '14

Hi! I have made a Powershell script that sets up a GHC build environment on Windows from scratch. It's at https://github.com/melted/getghc. It largely follows the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. It has no dependencies aside from Powershell 3.0. The reason I made it was to make it easier to set up a build bot on a clean machine. But it's probably generally useful for people who want to develop GHC on Windows. Usage: - Put the script in an empty directory - Run it - Hope for the best Potential problems: - If Python 2.7 is already installed and not on the path, the script wont install it, and msys wont pick up the path. Solution: Add the path to python in the control panel. - Powershell wont run unsigned scripts by default. The error message will give a hint how to disable that. I will add a signed version as soon as I can figure out how. Niklas

5 5

GHC rewrite rules and constructor wrappers?
by Conal Elliott 06 May '14

06 May '14

I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like > "reify/(:<)" reifyEP (:<) = kPrim VecSP This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire. Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC. -- Conal

2 1

Status updates
by Austin Seipp 06 May '14

06 May '14

Hi all, - The HCAR entry was quickly completed last week thanks to everyone, much appreciated for the quick response! And it made me aware of some other new things in the pipeline, too. :) - Simon is in-progress reviewing the ORF work still. But it's happening, so be patient of course (it's a large patch after all). - After a short discussion last week and a small grace period I killed external core, and removed all traces of it from the GHC tree. We constantly add things to GHC as Richard noted, so removing something was nice, even if a little sad. The result was about 3,000 fewer lines in the source tree. - I need to send a patch upstream to Ross for the AMP changes, but I slacked off a bit since the release of the new transformers got pushed back, pending some discussions on libraries(a)haskell.org - I'll be sending the results to Ross later today. - I spent some time working on removing the need for a build from creation of the source distribution like I mentioned last week - so 'make sdist' almost works out of the box. I believe it works fine, but it needs some more testing, and I feel like I should float the patch by for review on the list first, Simon in particular might have something to say. Do watch this space. - I'm going to continue working on trying HEAD with Stackage and putting the results somewhere, I just sort of left this as is right now. Also, remember from last week, the 7.8.3 milestone has been shaped up to be what we will look at - please do look over the tickets here when you get a chance! I'll be likely seeing if any new tickets will go here today: https://ghc.haskell.org/trac/ghc/milestone/7.8.3 https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&statu… Some other things worth noting: - It's time to merge up a lot of the patch queue. I'll be doing that soon - if you floated a patch by and want to discuss it or you want to make me aware of a patch you have, please let me know. At worst you will just inform me of something I already knew. - Side note, since a few people might be keen to know - Herbert took the time this week to move darcs.haskell.org onto a new server, effectively putting it in legacy mode. The switch has not yet happened, because we need to do a DNS switch. That's all, it was pretty light this week for me actually! We didn't actually have a call today yet actually, but we will have one next week and have more to say for sure. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Adding a dependency to the build system
by Mateusz Kowalczyk 05 May '14

05 May '14

Hi, Today I have split Haddock up a little to allow users to use the Haddock parser without incurring the dependency on GHC. This means the Haddock tree looks like this now: haddock/haddock.cabal haddock/src/… haddock/haddock-library/haddock-library.cabal haddock/haddock-library/src/… haddock/haddock-library/… haddock/… For details see [1]. In the haddock.cabal, we now depend on haddock-library. While this works fine in a regular development scenario, GHC build system needs to be made aware that it has to build haddock/haddock-library before haddock/. I tried looking at the build system but it is far too complicated to comprehend in a reasonable amount of time. Can someone already familiar with it make the change (in a separate branch or give me the diff so I can push the Haddock changes while at the same time updating submodule + build system) or tell me what exactly needs changing? haddock-library only uses a subset of Haddock's existing dependencies so there should be no problem on that end. A workaround would be to simply include haddock-library paths as additional source locations but I don't like it this approach as it breaks the ‘haddock-library is its own package’ abstraction. For example, this would not work if we ever wanted to move haddock-library to its own repository. Thanks! [1]: https://github.com/Fuuzetsu/haddock/tree/parser-split -- Mateusz K.

1 0