January 2014 - ghc-devs

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Páli Gábor János 30 Jan '14

30 Jan '14

On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp <aseipp(a)pobox.com> wrote: > The 7.8 branch is officially ready for RC1 (after some final Haddock > bugs got quickly squashed by Gergo and Mateusz.) Excellent, folks! > Alternatively, simply checking out to the 'ghc-7.8' branch will result > in the same thing - no new commits will go in until after RC1: > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > $ cd ghc-7.8 > $ ./sync-all get -b ghc-7.8 --extra --nofib For some reason, I get this for the last command: == running git clone git://git.haskell.org/libffi-tarballs.git libffi-tarballs -b ghc-7.8 --extra --nofib error: unknown option `extra'

2 1

7.8 branch is created, HEAD is now open, and a note on merges
by Austin Seipp 30 Jan '14

30 Jan '14

Hello all, I've just created the 7.8 branch after tying off some of the final loose ends. In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon: - OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!) I'll send a (GPG-signed) email containing SHA1 hashes when they're done. Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): - Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. This means I'll (mostly) be waiting around today, so feel free to shoot questions. As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change. Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen: * Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what? 1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed. * There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-commits(a)haskell.org which is related to your commit, and just say "Please merge" or somesuch. I'll come over the commits with such a response. This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP. If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 11

GHC for iOS (arm) 7.8 Preview Build ready for upload
by Luke Iannini 30 Jan '14

30 Jan '14

Hi folks! I've just finished a preview build of GHC for iOS off the 7.8 branch, but could use a place to upload it. And once that's done, if anyone would like to help me test it that has Xcode 5 and a device, that would be excellent! Cheers Luke

1 1

Unit tests for GHC code?
by Joachim Breitner 29 Jan '14

29 Jan '14

Hi, I am currently working on a piece of code (an analysis to solve #7994) where I’d like to make sure that my changes do not regress over what I had before. But I find it unnecessarily hard to write our usual test-case styles for them: * I’d like to test against very small Core that does not involve anything unnecessary. But it is hard to write Haskell that has, when it hits my analysis, this shape. It requires lots of {-# NOINLINE #-} and other tricks. * To test the result, I either have to write a performance test, but it is not always easy to come up with a program where the gains are massive enough to become a reliable test. It is possible, but work, and doing it maybe half a dozen times for various inputs is tricky. * Alternative, I can dump the Core and add that to the test cases. But now other changes to the compiler can easily trigger my test case failing. So I thought about writing a test case that simply imports my module from the ghc library, generates artificial, minimal core, and checks the output for precisely what I want (in my case, some fields of the IdInfo of various binders). I don’t see any examples for that in the test suite. Is that just because noone has done that before, or is there inherently bad about this approach that we do _not_ want to that? Also, we don’t have a parser for Core, so I’ll have to build my syntax trees using the stuff from MkCore et al, right? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

5 7

Pattern synonyms for 7.8?
by Dr. ERDI Gergo 29 Jan '14

29 Jan '14

Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo

11 13

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Kazu Yamamoto 29 Jan '14

29 Jan '14

Austin, > For the record, this error occurs fairly late in the ./validate script > - it's for testing the in-place binary distribution after a build, but > before the testsuite is run. In the mean time, you can just do 'cd > testsuite && make fast' to run all your tests after you have seen this > error. I simply do not have a sensible, easy fix right now. OK. I understand. P.S. I obtained Mac pro. Building and validating GHC on Mac pro are very quick. So, if necessary, please feel free to ask me to check building or validating GHC on Mac anytime. --Kazu

3 3

fPIC issues
by Jan Stolarek 28 Jan '14

28 Jan '14

A couple of days ago I realized that I can't compile latest HEAD on my Debian Squeeze laptop. Some -fPIC issues prevented compilation of integer-gmp library. I reported this as #8666. Today I got another PIC-related error on a different machine with openSUSE 11.4: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: dist/build/compile/compile-tmp/Data/Singletons/Core.dyn_o: re location R_X86_64_PC32 against undefined symbol `DataziSingletonsziTypes_Proved_con_info' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status This happened with HEAD when I tried to compile testsuite configured via cabal file (on 7.6.3 all is fine): test-suite compile type: exitcode-stdio-1.0 ghc-options: -Wall -O0 -main-is Test.Main default-language: Haskell2010 main-is: Test/Main.hs Before I fil in another bug report could someone offer me a straightforward explanation of what is this whole -fPIC thing? Why does it break my code? Is this a known issue? Is there any kind of workaround for this? Janek

3 4

GHC API: Using runGhc twice or from multiple threads?
by Benno Fünfstück 26 Jan '14

26 Jan '14

Hello, is the following safe to do? main = do runGhc libdir $ do ... runGhc libdir $ do ... Or will this cause trouble? Is there state that is shared between the two calls? And what about this one: main = do forkIO $ runGhc libdir $ do ... forkIO $ runGhc libdir $ do ...

4 5

Re: [commit: ghc] master: Fix more 32 bit performance fallout. (c5088e2)
by Simon Marlow 24 Jan '14

24 Jan '14

On 22/01/14 23:32, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/c5088e299a66109346057afc151c33e47… > >> --------------------------------------------------------------- > > commit c5088e299a66109346057afc151c33e47b850b92 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Wed Jan 22 17:30:54 2014 -0600 > > Fix more 32 bit performance fallout. > > Some of these are actually worse than I thought upon inspection, but > after a little digging I haven't found exactly what has caused them. > Some were certainly bitrotted, but others seem updated more recently, so > something has slipped. > > I'll be filing a ticket about these. Please do! These look very bad indeed. Cheers, Simon

1 1

Re: A modest proposal (re the Platform)
by Jens Petersen 24 Jan '14

24 Jan '14

On 20 January 2014 17:29, Andres Löh <andres.loeh(a)gmail.com> wrote: > (2) Simply because GHC 7.8 is itself so long delayed and so full of > new features, I think it's realistic to assume that quite a few > library glitches will appear even after it's released. Also, GHC bugs > may be found only after formal release (despite all the hammering, the > use of GHC pre release isn't quite comparable with the amount of > testing it gets afterwards; IMHO, there might very well be need for a > GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as > possible, but how soon would that actually happen, realistically? > I know I already said "+1" but this is also a very valid standpoint. I guess the question is how long does HP want to wait for a stable ghc-7.8 release? There were already a number of important library updates planned for the HP release with ghc-7.6.3 - doing things more incrementally is also good I believe. Also as Andres mentioned in view of Mavericks. I know it is difficult but if ghc and haskell-platform could align their schedules better then things might be easier to plan in the future. Jens

4 5