August 2016 - ghc-devs

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 15 May '17

15 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

Improving trac notifications
by Matthew Pickering 13 Feb '17

13 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

Inlining Wiki Page
by Matthew Pickering 13 Jan '17

13 Jan '17

Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a newcomer to start working on GHC. The inliner is quite well contained, there are lots of open tickets with well-specified aims and lots of investigatory work to be done. So the purpose of this email is: 1. Please tag any tickets relevant to inlining/specialisation with "Inlining" 2. Any newcomers keen to get involved should read the wiki page and see if they can tackle one of the tickets there. Matt

3 3

timings for individual compiler passes (in rc3)
by Johannes Waldmann 07 Dec '16

07 Dec '16

Hi. There is this (closed) https://ghc.haskell.org/trac/ghc/ticket/11653 and it's landed in 8.rc3. Thats good, and I want to make an effort to use this. But how? Just "-v2"? This gives a lot of noise. And no summary? Automatic analysis (of the output text stream, by external program) could be somewhat easier if each data set (starting at "\n!!!") did occupy exactly one line (currently, line breaks do occur). Anyway, what do I look for? Any large or suspicious number - but what exactly is "suspicious"? Anything above 1 second? Are we to believe the assignment of cost to pass, or could there be mis-attribution because result of an earlier pass is only forced later? Oh, and where do you want discussion of this feature (mailing list, ticket, ...)? I do hope that it will prove useful, in the sense that it could allow non-developers like me, or even build bots, to help spot performance problems. (E.g., you could advertise to enable this on travis. Yes, their build times depend on a lot of things, but still.) - J.W.

3 6

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 28 Sep '16

28 Sep '16

Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S.

6 7

Is Safe Haskell intended to allow segfaults?
by Ryan Newton 17 Sep '16

17 Sep '16

We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says: <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskel…> *Functions in the IO monad are still allowed and behave as usual. * As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe language you can trust the types", and I'd always assumed that meant Safe Haskell is a type safe language, even in the IO fragment. Was there an explicit decision to allow segfaults and memory corruption? This can happen not just with FFI calls but with uses of Ptrs within Haskell, for example the following: ``` {-# LANGUAGE Safe #-} module Main where import Foreign.Marshal.Alloc import Foreign.Storable import Foreign.Ptr import System.Random fn :: Ptr Int -> IO () fn p = do -- This is kosher: poke p 3 print =<< peek p -- This should crash the system: ix <- randomIO pokeElemOff p ix 0xcc main = alloca fn ``` -Ryan

10 23

RE: vectorisation code?
by Simon Peyton Jones 13 Sep '16

13 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

Phabricator diffs not viewable by non-logged in users
by Edward Z. Yang 02 Sep '16

02 Sep '16

For example, if I am not logged in (try an incognito/private browsing session), https://phabricator.haskell.org/D2501 reports an error. Is this intentional? Seems poor, and also the diff is labeled as Public in the UI. I found this quite surprising. Edward

3 2

Last call for merge requests for 8.0.2
by Ben Gamari 01 Sep '16

01 Sep '16

tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up! Hello everyone, Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2. If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket. Thanks! - Ben

5 7