February 2014 - ghc-devs

Nightlies
by Mateusz Kowalczyk 08 Feb '14

08 Feb '14

Hi all, I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. Does anything specific need doing to get these to run again? [1]: https://ghc.haskell.org/trac/ghc/wiki/Builder -- Mateusz K.

10 22

Support for glibc 2.12 in 7.8 RC2
by Rob Stewart 08 Feb '14

08 Feb '14

Hi, The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that RC2 will support glibc 2.13 to target Debian 7. CentOS 6 packages glibc 2.12 and this will be the glibc version in the CentOS 6 lifetime. Is there a possibility of stretching lower bounded support in RC2 down to glibc 2.12? This would allow all CentOS users using any of the 6.* releases to use 7.8, I think. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1 -- Rob

3 2

GHC iOS 7.8.1 RC1 for Device & Simulator
by Luke Iannini 06 Feb '14

06 Feb '14

Hi folks, RC builds of GHC iOS are now ready for devices and the iOS simulator. https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device… https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simula… You'll find complete instructions on their usage here, including compiling cabal packages: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Please let me know how it goes! Cheers Luke

2 1

Re: [commit: ghc] master: Mention that MR is off by default in GHCi in documentation (5bda0d0)
by Gabor Greif 06 Feb '14

06 Feb '14

It would be probably clearer to say "Since GHC 7.8.1, the monomorphism restriction is switched off by default in GHCi." This makes the awkward double-negation feeling go away. What do others think? Cheers, Gabor On 2/6/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d23… > >>--------------------------------------------------------------- > > commit 5bda0d08d8fec86433917b65a93836d2372a5b5c > Author: Krzysztof Gogolewski <krz.gogolewski(a)gmail.com> > Date: Wed Feb 5 20:40:13 2014 +0100 > > Mention that MR is off by default in GHCi in documentation > > >>--------------------------------------------------------------- > > 5bda0d08d8fec86433917b65a93836d2372a5b5c > docs/users_guide/glasgow_exts.xml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/docs/users_guide/glasgow_exts.xml > b/docs/users_guide/glasgow_exts.xml > index a3913cc..1564f38 100644 > --- a/docs/users_guide/glasgow_exts.xml > +++ b/docs/users_guide/glasgow_exts.xml > @@ -7862,7 +7862,8 @@ scope over the methods defined in the > <literal>where</literal> part. For exampl > 4.5.5</ulink> > of the Haskell Report) > can be completely switched off by > -<option>-XNoMonomorphismRestriction</option>. > +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is > +switched off by default in GHCi. > </para> > </sect3> > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

4 3

Bad news: apparent bug in casMutVar going back to 7.2
by Ryan Newton 06 Feb '14

06 Feb '14

I commented on the commit here: https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b The problem is that our "cas" routine in SMP.h is similar to the C compiler intrinsic __sync_val_compare_and_swap, in that it returns the old value. But it seems we cannot use a comparison against that old value to determine whether or not the CAS succeeded. (I believe the CAS may fail due to contention, but the old value may happen to look like our old value.) Unfortunately, this didn't occur to me until it started causing bugs [1] [2]. Fixing casMutVar# fixes these bugs. However, the way I'm currently fixing CAS in the "atomic-primops" package is by using __sync_bool_compare_and_swap: https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256d… What is the best fix for GHC itself? Would it be ok for GHC to include a C compiler intrinsic like __sync_val_compare_and_swap? Otherwise we need another big ifdbef'd function like "cas" in SMP.h that has the architecture-specific inline asm across all architectures. I can write the x86 one, but I'm not eager to try the others. Best, -Ryan [1] https://github.com/iu-parfunc/lvars/issues/70 [2] https://github.com/rrnewton/haskell-lockfree/issues/15

4 16

ghc-ios 7.8 working build
by Luke Iannini 05 Feb '14

05 Feb '14

Hi all, I believe I've worked around the issues with make binary-dist and cross-compilation. This should be a working binary for iOS devices https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device… Please try ./configure && make install (it should live happily next to your current ghc as arm-apple-darwin10-ghc) and let me know so we can have a build ready for 7.8 RC2! Cheers Luke

2 5

doc fix
by Kazu Yamamoto 05 Feb '14

05 Feb '14

Hi, If I understand correctly, NoMonomorphismRestriction is now the default for GHC 7.8. I think that its document explicitly describes it. --Kazu

3 2

GHC iOS make binary-dist
by Luke Iannini 05 Feb '14

05 Feb '14

Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the "make binary-dist" machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of "make binary-dist" on a tree after a successful "make" for arm-apple-darwin10 (which will "make install" perfectly). http://lpaste.net/99475 Cheers Luke

1 3

Cabal release for 7.8
by Johan Tibell 04 Feb '14

04 Feb '14

Hi, I guess we need one last cabal release for 7.8? Are we ready for that now, or do you expect any more 7.8 change that will require cabal changes? -- Johan

2 2

Summarize #7602
by Andrew Farmer 04 Feb '14

04 Feb '14

I know that #7602 has been mentioned as a final loose end in the RC. I was wondering if someone in the know could summarize its status in regards to how it effects GHC users. Feel free to be blisteringly brief... ;-) I'm just looking for things like: "this is a non-issue on modern OS X/Clang" or "it'll be fixed soon just be patient" or "we've done our part, this is Apple's problem now". I gave the trac thread a read-through, but there seems to be several degrees of flexibility/workarounds, so I'm still not sure if this is something I should worry about on my OS X machine. Thanks for your cycles! Andrew

3 2