June 2014 - ghc-devs - Haskell.org

Adding atomic primops
by Johan Tibell 09 Jun '14

09 Jun '14

Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan

7 22

[PATCH] Fix -unawareness of large-addresses on mingw (#8520)
by transfuturist 08 Jun '14

08 Jun '14

--- compiler/main/SysTools.lhs | 1 + 1 file changed, 1 insertion(+) diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index dc9642d..1cf1155 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do [ -- Reduce ld memory usage "-Wl,--hash-size=31" , "-Wl,--reduce-memory-overheads" + , "-Wl,--large-address-aware" --Trac #8520 -- Increase default stack, see -- Note [Windows stack usage] , "-Xlinker", "--stack=0x800000,0x800000" ] -- 1.8.4.msysgit.0

3 4

Re: GHC/cabal release procedures, and Stackage
by Joachim Breitner 08 Jun '14

08 Jun '14

Hi, Am Sonntag, den 08.06.2014, 07:55 +0300 schrieb Michael Snoyman: > > Actually, GHC HEAD isn't the problem I'm running into right now. I'm > already testing that[1] using Herbert's Ubuntu PPA[2] Ah, cool! > I'm specifically looking for builds off of the 7.8 branch so I can > start testing point releases. Then I guess the easiest would be if Herbert would add that to his PPA. > [2] And in case anyone's curious, restrictive upper bounds on > transformers and template-haskell are preventing a build right now. Hmm, it would be nice if cabal had a “best effort” mode where when some of the requested packages cannot be built it at least builds the rest. Also, isn’t there a new flag to cabal to selectively ignore upper bounds? (I can’t find the documentation for the latest cabal-install online right now.) 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 1

Re: [GHC] #8226: Remove the old style -- # Haddock comments.
by Alfredo Di Napoli 07 Jun '14

07 Jun '14

Thanks Fuuzetsu, Tomorrow I'll still be at the ZuriHac, so hopefully I'll able to adjust the patch :) I'll poke you if you'll be around Thanks! Alfredo Di Napoli > On 07/giu/2014, at 07:23, "GHC" <ghc-devs(a)haskell.org> wrote: > > #8226: Remove the old style -- # Haddock comments. > -------------------------------------+------------------------------------ > Reporter: Fuuzetsu | Owner: > Type: task | Status: patch > Priority: normal | Milestone: 7.10.1 > Component: Compiler | Version: 7.7 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by Fuuzetsu): > > Sorry I fell behind a bit on reading GHC tickets. > > Yes adinapoli, those should also be removed, we do not use --# for > anything and it served the same purpose as {-# as far as I know. > > Also the data type used to store that type of comment should be removed: > > https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L625 > > FTR the Haddock ticket is now tracked at > https://github.com/haskell/haddock/issues/171 > > Thanks for looking into this, feel free to poke me on IRC/e-mail if you > need more immediate review. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler

1 0

7.8.3 release - please speak up soon.
by Austin Seipp 07 Jun '14

07 Jun '14

Hello all, I'm going to do the 7.8.3 release very soon. Now is the time to speak up if something should go in. Here's the take away from this: I *am not* going to fix any other bugs for 7.8.3 or close any other tickets than the following: - #9155 https://ghc.haskell.org/trac/ghc/ticket/9155 - #7241 https://ghc.haskell.org/trac/ghc/ticket/7241 - #8683 https://ghc.haskell.org/trac/ghc/ticket/8683 - #8935 https://ghc.haskell.org/trac/ghc/ticket/8935 - #9080 https://ghc.haskell.org/trac/ghc/ticket/9080 The first one is a bug fix from Simon for the code generator. The remaining ones are patches I intend to land today. So here's the deal: if you don't speak up now, you'll have to wait until 7.8.4 (sometime in the late summer I imagine) to get your word in. Is there anything anyone absolutely must have that I've missed? Full details on what was fixed are on this page - the 'infoneeded' and 'new' tickets will be punted to a new milestone shortly. All 'closed' tickets are merged and in the 7.8 branch already: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

Re: Offering GHC builder build slaves
by Páli Gábor János 07 Jun '14

07 Jun '14

2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg <lyndon(a)orthanc.ca>: > Is there any way to verify that builder-client can actually do a successful build, > without having access to the build system server? 'builder-client --do-build' > wants to connect and authenticate first; it would be helpful if there was a way > to bypass that so that I can first verify the local build environment is sane. This is because the builder client gets the commands to be executed from the server. A naive solution would be to put the commands in the script and run it. You can find the current set of installed commands at one of the active builders page, e.g. [1]. Note that you may have to change some of them, such as the flags passed to configure script and name of the make(1) command. [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html

3 3

RE: GHC/cabal release procedures, and Stackage
by Simon Peyton Jones 06 Jun '14

06 Jun '14

Michael I think that would be great. Absolutely: the earlier we can catch regressions the better. Couldn’t we make it part of the continuous-integration builds (Travis?) that various folk are running, eg. Joachim? I’m hazy about how all of this works, but I’d love it just to happen automatically every night or whatever, with failure being reported by email, with instructions on how to reproduce the failure. Might you work with Joachim and others to make that possible? Thanks for suggesting it Simon From: Michael Snoyman [mailto:michael@fpcomplete.com] Sent: 05 June 2014 17:10 To: Simon Peyton Jones Subject: GHC/cabal release procedures, and Stackage Hi Simon, I wanted to bring up an idea I've been playing with for a few weeks now. The past few releases of GHC and cabal-install have introduced regressions that were not caught by test suites, but were caught by building code from Hackage. In particular, I discovered some of these bugs almost immediately after release by doing normal Stackage builds. So I'd like to propose that part of the GHC and cabal-install release processes include trying to run a build of Stackage. This should be both a good stress test, plus- since Stackage covers the majority of actively used packages- should also be a good indication that early adopters of the new version won't immediately hit bugs. I'm happy to volunteer to be a part of this process (e.g., to be the guy who actually runs the builds). As a user, I'd definitely appreciate the opportunity to iron out bugs before they hit the light of day and start causing larger headaches. What do you think? Thanks, Michael PS: A relevant issue is an upcoming yesod-bin breakage in GHC 7.8.3: https://github.com/yesodweb/yesod/issues/748. I haven't been able to investigate this myself since there seems to be a build bug for 7.8.3 when using the Gold linker.

2 1

Status updates
by Austin Seipp 06 Jun '14

06 Jun '14

Hello all, A cumulative status update will now appear, to summarize a few things that have happened in the past little while since I've been somewhat absent and short on time. - 7.8.3 is looming, because we have a lot of bugfixes as I said last week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 That's nearly 30 tickets axed in the past few weeks since 7.8.2, so not bad! As I said before, I'm eager to release sooner rather than later as my time is short. Do keep weighing in if you have anything to say or want something fixed. Now is really the time! - AMP/ORF - these are still on branches, but me and Simon have gotten hung up on a few things delaying it. They'll go in soon, promise! (For certain definitions of 'soon', cooperating with time schedules). AMP in particular can probably land very, very soon. Otherwise we're past a lot of other churn, like removing external core and whatnot. - I merged a bunch of patches this morning to the 7.8 branch, bringing it close to what I expect we will ship 7.8.3 with. Again, pester me soon if you want something! - There's now a proper CI link for GHC on Trac so people don't lose it. The new builders are checking in regularly, so please watch out for them - and subscribe to ghc-builds(a)haskell.org if you haven't already. - Some other churn in the tree has not yet passed; I still need to improve and land my performance patches for copies, for example. - XCode 5.1 has introduced some other breaking changes I'll need to fix (things *work*, but the testsuite is useless due to the warning spewage), along with merging the remaining patches. - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will have better dedicated Windows targets soon. I'll send another email about 7.8.3 shortly. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 6

pushing to haddock
by Simon Peyton Jones 06 Jun '14

06 Jun '14

I'm trying desperately to follow the instructions on https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules for how to update haddock to follow a small change to GHC. I've checked out the haddock master, made my patch, and want to push to haddock. But my push is rejected for an inscrutable reason: git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean) simonpj@cam-05-unx:~/code/HEAD-2/utils/haddock$ git push Counting objects: 9, done. Delta compression using up to 32 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 470 bytes, done. Total 5 (delta 4), reused 0 (delta 0) remote: W refs/heads/master haddock simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/master To ssh://git@ghc.haskell.org/haddock.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://git@ghc.haskell.org/haddock.git' simonpj@cam-05-unx:~/code/HEAD-2/utils/haddock$ What do I do now? Presumably once that's done I include the change to utils/haddock in my patch to HEAD, correct? Getting to Haddock HEAD added 12 new patches on the haddock branch so I suppose they'll be included too. I don't know whether that is good or bad. help! Simon

2 6

haddock in 7.8.3
by Simon Peyton Jones 06 Jun '14

06 Jun '14

I want to change the interface to PatSyn.patSynSig, as part of fixing a bug in 7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock on change to Haddock Is that acceptable in a 7.8.3 release cycle? If not, I can program round it in the 7.8.3 branch. But if it's not a problem, it'd be a bit easier just to make the change in Haddock? (Really Haddock has to be co-released with GHC, since it depends on many internal GHC details.) Simon

2 1