February 2015 - ghc-devs

Writing a subtype function
by Izzy Meckler 23 Feb '15

23 Feb '15

Hi all, I apologize if this isn’t the right place for this sort of question, but I’m at a loss as to how to use TcUnify.tcSubType. My goal is to write a function of type Type -> Type -> Ghc Bool which checks whether the first argument is a subtype of the second. I assume this is possible to do using TcUnify.tcSubType and runTcInteractive, but it’s not clear to me how. Any pointers here would be greatly appreciated.

2 2

Desugaring introduces
by Gabor Greif 23 Feb '15

23 Feb '15

Hi devs, before I file a bug, I'd like to double check on a strange desugaring behaviour with RankNTypes and RebindableSyntax. Here is the snippet {{{ {-# LANGUAGE RankNTypes, RebindableSyntax #-} {-# LANGUAGE ImpredicativeTypes #-} import qualified Prelude as P (>>=) :: a -> ((forall b . b) -> c) -> c a >>= f = f P.undefined return a = a fail s = P.undefined t1 = 'd' >>= (\_ -> 'k') t2 = do _ <- 'd' 'k' main = P.putStrLn [t1, t2] }}} Without ImpredicativeTypes I get this error: {{{ rebindtest.hs:13:9: Cannot instantiate unification variable ‘t0’ with a type involving foralls: forall b. b Perhaps you want ImpredicativeTypes In a stmt of a 'do' block: _ <- 'd' In the expression: do { _ <- 'd'; 'k' } In an equation for ‘t2’: t2 = do { _ <- 'd'; 'k' } }}} t1 is supposed to be the desugaring of t2. Strangely t2 only compiles with ImpredicativeTypes. Why? Isn't desugaring a purely syntactic transformation (esp. with RebindableSyntax)? Any hints welcome! Cheers, Gabor

3 3

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
by Miëtek Bak 21 Feb '15

21 Feb '15

My previous email was about the x86_64 bindist GHC 7.10.1-rc2. I’ve now added i386 support to Halcyon, and it appears only the x86_64 version works fine on CentOS 6 (6.5), while the i386 version fails to configure: checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi-ghc7.10.0.20150123.so: undefined symbol: __gmpn_andn_n configure: error: cannot determine current directory -- Miëtek On 2015-01-27, at 06:26, Miëtek Bak <mietek(a)bak.io> wrote: > It appears GHC 7.10.1-rc2 doesn’t support glibc 2.11 — specifically, 2.11.1 (Ubuntu 10.04 LTS) and 2.11.3 (Debian 6). glibc 2.12 (CentOS 6) seems to work fine. Symptoms include: > > Installing library in > /app/ghc/lib/ghc-7.10.0.20150123/ghc_0kOYffGYd794400D7yvIjm > "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" --force --global-package-db "/app/ghc/lib/ghc-7.10.0.20150123/package.conf.d" update rts/dist/package.conf.install > Reading package info from "rts/dist/package.conf.install" ... done. > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc" "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" "/app/ghc/lib/ghc-7.10.0.20150123" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150123' '/app/ghc/share/doc/ghc/html/libraries' NO > Warning: cannot determine version of /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc > : > "" > ghc-cabal: '/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc' exited with an error: > /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc: symbol lookup error: > /app/ghc/lib/ghc-7.10.0.20150123/bin/../rts/libHSrts_thr-ghc7.10.0.20150123.so: > undefined symbol: pthread_setname_np > > The bindist name does mention 'deb7', so perhaps this is all working as intended. However, similarly named bindists for GHC 7.8.* work fine with glibc 2.11. > > > In other news, I’m happy to say Halcyon now supports GHC 7.10.1-rc2 on CentOS 6 and 7, Debian 7, Fedora 19, 20, and 21, and Ubuntu 12 and 14. > https://halcyon.sh/ > > $ halcyon install --ghc-version=7.10.1-rc2 --cabal-version=1.22.0.0 > > > Best, > > -- > Miëtek > > > > > On 2015-01-27, at 00:13, Austin Seipp <austin(a)well-typed.com> wrote: > >> We are pleased to announce the second release candidate for GHC 7.10.1: >> >> https://downloads.haskell.org/~ghc/7.10.1-rc2/ >> >> This includes the source tarball and bindists for 64bit/32bit Linux >> and Windows. Binary builds for other platforms will be available >> shortly. (CentOS 6.5 binaries are not available at this time like they >> were for 7.8.x). These binaries and tarballs have an accompanying >> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >> >> We plan to make the 7.10.1 release sometime in February of 2015. >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 1

Re: Behavior change of Data.Char
by David Feuer 20 Feb '15

20 Feb '15

I don't think so. There's no guarantee that future versions will maintain it, and I don't know that we want to take responsibility for continually checking on that. David On Feb 20, 2015 Simon Peyton Jones wrote: > It'd be good to document this condition/invariant in the Haddocks, wouldn't it?! > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of > | Herbert Valerio Riedel > | Sent: 19 February 2015 10:42 > | To: Kazu Yamamoto > | Cc: libraries(a)haskell.org; ghc-devs(a)haskell.org > | Subject: Re: Behavior change of Data.Char > | > | On 2015-02-19 at 06:19:18 +0100, Kazu Yamamoto (????) wrote: > | > It seems to me that some characters of GHC 7.10.1RC2 behave > | > differently from those of GHC 7.8.4: > | > > | > 7.8.4 7.10.1RC2 > | > isLower (char 170) True False > | > | Fwiw, the motivation for that particular change may be (I'm just > | guessing here) to have the following condition hold: > | > | \c -> isLower c `implies` (not . isLower . toUpper) c > | > | i.e. if something is 'lower-case', then applying 'toUpper' should > | result in a character that is not 'lower-case' anymore. This didn't > | hold with 7.8.4's Unicode 6, but now holds with 7.10.1's Unicode 7 > | definitions. > | > | Cheers, > | hvr > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

76-fold regression GHC 7.10->7.11 in T9961 byte-allocation
by Herbert Valerio Riedel 20 Feb '15

20 Feb '15

Hello *, I noticed something odd while validating the GHC 7.10 branch: bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 9766160 Deviation T9961(normal) bytes allocated: -98.7 % *** unexpected stat test failure for T9961(normal) ...then I also ran ./validate against today's GHC HEAD, and re-ran the T9961 test: Expected T9961(normal) bytes allocated: 772510192 +/-5% Lower bound T9961(normal) bytes allocated: 733884682 Upper bound T9961(normal) bytes allocated: 811135702 Actual T9961(normal) bytes allocated: 748225848 Deviation T9961(normal) bytes allocated: -3.1 % I'm not sure if it's just the test-case being broken, or there's something real regression between 7.10 and HEAD... However, I don't have time to investigate this. Cheers, hvr

2 1

Behavior change of Data.Char
by Kazu Yamamoto 19 Feb '15

19 Feb '15

Hi, It seems to me that some characters of GHC 7.10.1RC2 behave differently from those of GHC 7.8.4: 7.8.4 7.10.1RC2 isLower (char 170) True False isSymbol (chr 182) True False isPunctuation (chr 182) Fase True Is this intentional? I noticed this because I received a bug report: https://github.com/kazu-yamamoto/word8/issues/3 As you can see, 167 also behaves differently. --Kazu

5 5

RE: Resolving Windows 64-bit linker issues
by Tamar Christina 18 Feb '15

18 Feb '15

Hi Simon, We do have a page on Trac with the members: https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce We could add the extra information there. Regards, Tamar ------------------------------ From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: ‎17/‎02/‎2015 10:18 To: Darren Grant <dedgrant(a)gmail.com>; Mikolaj Konarski <mikolaj(a)well-typed.com> Cc: Phyx <lonetiger(a)gmail.com>; Roman Kuznetsov <kuznero(a)gmail.com>; ghc-devs(a)haskell.org; David Macek <david.macek.0(a)gmail.com>; kyrab <kyrab(a)mail.ru>; Gintautas Miliauskas <gintautas(a)miliauskas.lt>; Martin Foster <martin.e.foster(a)gmail.com> Subject: RE: Resolving Windows 64-bit linker issues One really helpful thing would be to · make a wiki home page for the Windows Task Force · list who is on it · list the main tasks “in flight” and what their status is · any other plans Anything to broaden visibility of the WTF, and encourage others to join in. Communication is all in an open-source context! Thanks for working on Windows… it’s a very popular platform, and needs your love! Simon *From:* Darren Grant [mailto:dedgrant@gmail.com] *Sent:* 17 February 2015 05:03 *To:* Mikolaj Konarski *Cc:* Phyx; Roman Kuznetsov; ghc-devs(a)haskell.org; Simon Peyton Jones; David Macek; kyrab; Gintautas Miliauskas; Martin Foster *Subject:* Re: Resolving Windows 64-bit linker issues To expand on that (let's see if I can do this without accidentally sending again, oops!): Roman, I will get in touch with you on a separate email thread to see if we can find an optimal way to coordinate, something that satisfies our schedules and needs. Others please feel free to bug me any time by email ( dedgrant(a)gmail.com) or on freenode #ghc as dedgrant, PST hours. In the meantime I'll be auditing some of the related backlogged tickets on trac. If there's something I can do to help further the goal of a Windows Task Force page, please let me know. Pleased to meet everyone! Cheers, Darren On Mon, Feb 16, 2015 at 8:48 PM, Darren Grant <dedgrant(a)gmail.com> wrote: Thank you kindly for the great introduction. I hope I can be helpful here. On Feb 16, 2015 7:47 AM, "Mikolaj Konarski" <mikolaj(a)well-typed.com> wrote: Resending, since Roman's and Kyril's email addresses were mangled/missing. On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Darren > > > > Excellent! We have a Windows Task Force, consisting roughly of the folk in > cc. So they would be the first group to ask. > > > > (I think it would be very helpful to have a Windows Task Force home page, so > that it’s easier to find the group.) > > > > thanks for helping with Windows. > > > > Simon > > > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Darren > Grant > Sent: 15 February 2015 07:36 > To: ghc-devs(a)haskell.org > Subject: Resolving Windows 64-bit linker issues > > > > Hi all, > > > > I notice there are a series of related long-standing issues subject to > particular cygwin64 quirks, and I'd like to offer time to help resolve these > if possible > > At this point I've had some exposure to the GHC build process (7.8.3), and > have poked around the GHC linker to gain some low level insight. > > > > Would anyone be available to fill me in on the current state of affairs with > mingw64 GHCi linking? For instance, is there ongoing work, or perhaps a > preferred direction but no available developer bandwidth to proceed? > > > > Thank you. > > > > Cheers, > > Darren > >

6 9

GHC Weekly News - 2015/02/17
by Austin Seipp 18 Feb '15

18 Feb '15

Hi *, It's time for the GHC weekly news. It's been particularly quiet the past week still, and the `ghc-7.10` branch has been quite quiet. So the notes are relatively short this week. This week, GHC HQ met up to discuss some new stuff: - Most of the discussion this week was about particular bugs for GHC 7.10, including getting some tickets fixed like #10058, #8276, and #9968. - Since the 7.10 release is getting close, we'll be starting up a new status page about GHC 7.12 (and probably get started writing things for the HCAR report in May) and what our plans are soon. Watch this space! As usual, we've had a healthy amount of random assorted chatter on the mailing lists: - Simon Peyton Jones opened the polls for the GHC 7.10 Prelude changes this week, following the discussions and delay of the 7.10 release, as to what the new Prelude should look like. Simon's email has all the details - and voting ends next week! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008290.html - Hengchu Zhang popped up on the list as an excited new contributor, and wanted to know about the process strategy for fixing a bug. Joachim was quick to respond with help - and welcome Hengchu! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008324.html - Francesco Mazzoli has a question about Template Haskell, specifically the semantics of reification since 7.8. In short, the semantics of `reify` changed in 7.8, and Francesco was wondering if the old behavior should be supported. But while it could be, it discussion seems to indicate that perhaps it shouldn't. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008327.html - Darren Grant popped up on the list and asked: "I notice there are a series of related long-standing issues subject to particular cygwin64 quirks, and I'd like to offer time to help resolve these if possible". Darren wanted some pointers, and they were given! GHC on Windows crucially still needs dedicated developers; the email sparked up a bunch of chatter amongst Windows developers on the list as well, so hopefully life is coming back to it. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008333.html - Jan Stolarek hit a confusing error when trying to install `vector` with HEAD and asked for help. The quick reply: you need support for the new `deepseq` package, which hasn't been merged upstream yet. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008349.html - Francesco Mazzoli had a simple feature request: could we have anonymous FFI calls that don't require a name? https://mail.haskell.org/pipermail/ghc-devs/2015-February/008300.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit e22282e5d2a370395535df4051bdeb8213106d1c - GHC 7.12 will no longer ship with the `Typeable.h` header file. - Commit 5d5abdca31cdb4db5303999778fa25c4a1371084 - The LLVM backend has been overhauled and updated to use LLVM 3.6 exclusively. Closed tickets the past week include: #10047, #10082, #10019, #10007, #9930, #10085, #10080, #9266, #10095, and #3649. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Seeking an active maintainer for 'directory'
by Edward Kmett 18 Feb '15

18 Feb '15

The 'directory' package could use an active maintainer. Currently, the package falls to the Core Libraries Committee for maintenance, but we've had a number of issues accrete for the directory package over the last six months or so, which need some attention to detail and a good understanding of cross-platform issues. Is anybody interested in nominating themselves for this role? -Edward

3 6

Building vector with GHC HEAD
by Jan Stolarek 17 Feb '15

17 Feb '15

Devs, I'm not sure if this is the best place to ask this question but I'm almost certain someone here will have the answer. I want to build upstream master branch of vector library using GHC HEAD and cabal 1.22. Alas my attempts have failed: $ git clone git@github.com:haskell/vector.git $ cd vector $ cabal sandbox init $ cabal install -w /dane/projekty/ghc/build/inplace/bin/ghc-stage2 Resolving dependencies... cabal: Could not resolve dependencies: trying: vector-0.11.0.0 (user goal) trying: base-4.8.0.0/installed-inp... (dependency of vector-0.11.0.0) next goal: deepseq (dependency of vector-0.11.0.0) rejecting: deepseq-1.4.0.0/installed-inp..., 1.4.0.0 (conflict: vector => deepseq>=1.1 && <1.4) rejecting: deepseq-1.3.0.2 (conflict: base==4.8.0.0/installed-inp..., deepseq => base>=4.3 && <4.8) trying: deepseq-1.3.0.1 next goal: array (dependency of deepseq-1.3.0.1) rejecting: array-0.5.0.1/installed-inp..., 0.5.0.0 (conflict: deepseq => array>=0.1 && <0.5) rejecting: array-0.4.0.1 (conflict: base==4.8.0.0/installed-inp..., array => base>=4.2 && <4.7) rejecting: array-0.4.0.0 (conflict: base==4.8.0.0/installed-inp..., array => base>=4.2 && <4.6) rejecting: array-0.3.0.3 (conflict: base==4.8.0.0/installed-inp..., array => base>=4.2 && <4.5) rejecting: array-0.3.0.2, 0.3.0.1 (conflict: base==4.8.0.0/installed-inp..., array => base>=4.2 && <4.4) rejecting: array-0.3.0.0 (conflict: base==4.8.0.0/installed-inp..., array => base>=3 && <4.4) rejecting: array-0.2.0.0, 0.1.0.0 (conflict: base==4.8.0.0/installed-inp..., array => base<4.3) Dependency tree exhaustively searched. The problem arises from vector requiring deepseq < 1.4 when intree package db contains deepseq 1.4. Removing the upper bound on deepseq in vector.cabal allows to resolve dependencies but ends with a build error: Data/Vector/Primitive/Mutable.hs:78:10: No instance for (GHC.Generics.Generic (MVector s a)) arising from a use of ‘Control.DeepSeq.$gdmrnf’ In the expression: Control.DeepSeq.$gdmrnf In an equation for ‘rnf’: rnf = Control.DeepSeq.$gdmrnf In the instance declaration for ‘NFData (MVector s a)’ Fixing this error (importing GHC.Generics & deriving `Generic` instance for `MVector s a`) leads to another one: Data/Vector/Primitive/Mutable.hs:80:10: No instance for (Control.DeepSeq.GNFData (Rep (MVector s a))) arising from a use of ‘Control.DeepSeq.$gdmrnf’ In the expression: Control.DeepSeq.$gdmrnf In an equation for ‘rnf’: rnf = Control.DeepSeq.$gdmrnf In the instance declaration for ‘NFData (MVector s a)’ This time I have no idea how to fix it since GNFData is an internal class of Control.Deepseq module. Help? Aside: at first I thought vector is one of the boot libraries since it is kept in the source tree. But then I realized it is not being build during bootstrapping. Why do we keep it in the source tree then? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

5 5