- ghc-devs - Haskell.org

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

08 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 06 May '14

06 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 05 May '14

05 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

C-- specfication
by Florian Weimer 05 May '14

05 May '14

I'm looking for a specification of C--. I can't find it on the cminuscminus.org web site, and it's also not included in the release tarball. Does anybody know where to get it?

6 8

Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
by Mateusz Kowalczyk 04 May '14

04 May '14

On 05/02/2014 03:50 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/b0534f78a73f972e279eed4447a5687bd… > >> --------------------------------------------------------------- > > commit b0534f78a73f972e279eed4447a5687bd6a8308e > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Mon Apr 28 16:55:47 2014 +0100 > > Per-thread allocation counters and limits > > This tracks the amount of memory allocation by each thread in a > counter stored in the TSO. Optionally, when the counter drops below > zero (it counts down), the thread can be sent an asynchronous > exception: AllocationLimitExceeded. When this happens, given a small > additional limit so that it can handle the exception. See > documentation in GHC.Conc for more details. > > Allocation limits are similar to timeouts, but > > - timeouts use real time, not CPU time. Allocation limits do not > count anything while the thread is blocked or in foreign code. > > - timeouts don't re-trigger if the thread catches the exception, > allocation limits do. > > - timeouts can catch non-allocating loops, if you use > -fno-omit-yields. This doesn't work for allocation limits. > > I couldn't measure any impact on benchmarks with these changes, even > for nofib/smp. > > >> --------------------------------------------------------------- > > b0534f78a73f972e279eed4447a5687bd6a8308e > compiler/cmm/CmmLayoutStack.hs | 9 +- > compiler/codeGen/StgCmmForeign.hs | 268 ++++++++++++++------ > includes/CodeGen.Platform.hs | 4 +- > includes/rts/Constants.h | 6 + > includes/rts/Flags.h | 8 + > includes/rts/Threads.h | 8 +- > includes/rts/storage/TSO.h | 31 ++- > libraries/base/Control/Exception.hs | 1 + > libraries/base/Control/Exception/Base.hs | 1 + > libraries/base/GHC/Conc.lhs | 6 + > libraries/base/GHC/Conc/Sync.lhs | 92 ++++++- > libraries/base/GHC/IO/Exception.hs | 21 +- > rts/HeapStackCheck.cmm | 4 +- > rts/Linker.c | 4 + > rts/Prelude.h | 2 + > rts/RaiseAsync.c | 54 ++++ > rts/RaiseAsync.h | 4 + > rts/RtsFlags.c | 10 + > rts/RtsStartup.c | 1 + > rts/Schedule.c | 19 ++ > rts/Threads.c | 77 +++--- > rts/package.conf.in | 2 + > rts/sm/Storage.c | 6 + > testsuite/tests/concurrent/should_run/all.T | 7 + > .../tests/concurrent/should_run/allocLimit1.hs | 9 + > .../tests/concurrent/should_run/allocLimit1.stderr | 1 + > .../tests/concurrent/should_run/allocLimit2.hs | 17 ++ > .../tests/concurrent/should_run/allocLimit3.hs | 15 ++ > .../tests/concurrent/should_run/allocLimit3.stderr | 1 + > .../should_run/allocLimit3.stdout} | 1 - > .../tests/concurrent/should_run/allocLimit4.hs | 31 +++ > utils/deriveConstants/DeriveConstants.hs | 1 + > 32 files changed, 576 insertions(+), 145 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc b0534f78a73f972e279eed4447a5687bd6a8308e > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > I just tried to compile a snapshot involving this commit and got a compile failure: http://lpaste.net/103540 I was compiling with GHC 7.8.2 on a 32-bit machine. -- Mateusz K.

7 10

Branch cleanup coming soon - please take inventory
by Austin Seipp 04 May '14

04 May '14

Hello all, I was talking about this on IRC the other day, and it reminded me I wanted to do this a while back. At the moment, we have a *lot* of branches hanging out in the GHC tree: $ git branch -r | grep origin | wc -l 89 $ So I'd like to start deleting all the old ones that are merged and don't need to hang around. A while back I kept a list that was curated of what branches were dead and could be removed. Here it is: https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches This page is a bit out of date, but still many of the comments are accurate, particularly what can already be deleted. I will likely be *deleting* these merged branches soon unless someone speaks up. Note that: - Anything I cannot be 100% certain is merged will stay. - Anything which is effectively 'in-limbo' (like local-gc, or supercompiler) will stay. We also have a lot of WIP branches here too. If you all would all take inventory of your branches and make sure they're catalogued on that page, it would be really nice. Just add it for now - I'll get rid of the old entries once I delete them later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

[PATCH] make UNREG build as a platform with 0 hardware registers
by slyich＠gmail.com 04 May '14

04 May '14

From: Sergei Trofimovich <slyfox(a)gentoo.org> 83a003fcaec93dbfd5b46837f2bf3353412b9877 introduced optimization which likes to know if a reg is a hardware reg via 'globalRegMaybe': But --enable-unregisterised does not define that function: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140419 for x86_64-unknown-linux): globalRegMaybe not defined for this platform CC: Simon Marlow <marlowsd(a)gmail.com> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- includes/CodeGen.Platform.hs | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index 3d6dd41..1e7c17d 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -743,7 +743,11 @@ globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery # endif globalRegMaybe _ = Nothing #else +# ifdef NO_REGS +globalRegMaybe _ = Nothing +# else globalRegMaybe = panic "globalRegMaybe not defined for this platform" +# endif /* !NO_REGS */ #endif freeReg :: RegNo -> FastBool -- 1.9.2

2 1