- ghc-devs - Haskell.org

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

ANNOUNCE: GHC 7.10.1 Release Candidate 2
by Austin Seipp 17 Feb '15

17 Feb '15

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/

11 17

Resolving Windows 64-bit linker issues
by Darren Grant 17 Feb '15

17 Feb '15

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

5 8

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

17 Feb '15

Hi Darren, I'm afraid I don't off the top of my head. I've never had to look at that file yet. On my way to work this morning I was reading up on what mingw64 uses .refptr for. So now I understand at least that part. But I'm afraid I can't offer any advice on how to tackle it in GHC at the moment. Regards, Tamar Sent from my Windows Phone ------------------------------ From: Darren Grant <dedgrant(a)gmail.com> Sent: ‎17/‎02/‎2015 06:57 To: Tamar Christina <lonetiger(a)gmail.com> Cc: Mikolaj Konarski <mikolaj(a)well-typed.com>; Roman Kuznetsov <kuznero(a)gmail.com>; ghc-devs(a)haskell.org; Simon Peyton Jones <simonpj(a)microsoft.com>; David Macek <david.macek.0(a)gmail.com>; kyra <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 Hi Tamar, Thank you for the offer. Do you have any thoughts or advice on approaching changes to the existing PE code in Linker.c? I'm wondering if this was destined to be extended into support for PE+ given the absence of .refptr and $. Cheers, Darren On Mon, Feb 16, 2015 at 9:10 PM, Tamar Christina <lonetiger(a)gmail.com> wrote: > Hi Darren, > > I don’t actually know what the status of these issues are. I think one of > the tasks we had set out to do was actually checking on these tickets and > their progress. > > Gintautas was doing most of the mingw64 build stuff. I don’t know if the > cygwin64 link stuff has been looked at by anyone since I think we’re all > mostly using mingw64. > > I have two issues I’m working on atm, both related to the RTS. But if > there’s anything I can do to help then just let me know. > > Cheers, > Tamar > > *From:* Darren Grant <dedgrant(a)gmail.com> > *Sent:* ‎Tuesday‎, ‎February‎ ‎17‎, ‎2015 ‎06‎:‎02 > *To:* Mikolaj Konarski <mikolaj(a)well-typed.com> > *Cc:* Phyx <lonetiger(a)gmail.com>, Roman Kuznetsov <kuznero(a)gmail.com>, > ghc-devs(a)haskell.org, Simon Peyton Jones <simonpj(a)microsoft.com>, David > Macek <david.macek.0(a)gmail.com>, kyra <kyrab(a)mail.ru>, Gintautas > Miliauskas <gintautas(a)miliauskas.lt>, Martin Foster > <martin.e.foster(a)gmail.com> > > 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 >>> > >>> > >>> >> >

1 0

Anonymous FFI calls
by Francesco Mazzoli 13 Feb '15

13 Feb '15

Hi, I am in a situation where it would be very useful to call C functions without an explicit FFI import. For example, I'd like to be able to do (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 instead of declaring the foreign import explicitely at the top level. Is there a way to do this or to achieve similar results in some other way? If not, I imagine it would be easy to implement such a facility in GHC, given that the code implementing calling to C functions must already be present to implement "proper" FFI imports. I think such an addition would be useful in many cases. Thanks, Francesco

6 16

What `reify` sees in Template Haskell
by Francesco Mazzoli 13 Feb '15

13 Feb '15

Hi, I recently stumbled upon the issue of `reify` not being able to give information about local variables, as of GHC 7.8. For example, this won't work: foo x = $(do {xInfo <- reify 'x; ...}) The motivation for this change is described here: <https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges#PartC…>. While I agree that getting the type of local variables is going to be brittle, I also think that offering that functionality is extremely useful in certain cases, such as in the case of the language-c-inline library, that used this facility to avoid having to type verbose type annotations -- see <https://github.com/mchakravarty/language-c-inline/issues/25>. My two part question is: 1. would it be possible to revert to the old behavior easily, or is doing that difficult or impossible now given the overall changes to the Template Haskell code? 2. if 1, wouldn't it make more sense to allow reifying all names if the user really wants, maybe with a specific `unsafeReify` function or similar? It should be made clear in the docs that by using `unsafeReify` the user is relying on GHC internals (specifically the internals of type checking). Also, I think that post should at least be referenced in the manual, for lack of better documentation. This behavior is not mentioned anywhere else. Thanks, Francesco

3 3