February 2017 - ghc-devs

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

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 14 May '17

14 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

Proposal: make throwIO and throw strict
by David Feuer 27 Feb '17

27 Feb '17

It's possible for code to throw an exception that itself throws an imprecise exception. Such an exception is a bit tricky to catch. For example: import Control.Exception strange = throwIO (undefined :: SomeException) `catch` \ex -> case () of _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" | otherwise -> print "Something else" You might think that this would catch the exception and print "Something else", but in fact it does not. If others think this is as surprising as I do, then I think we should make throwIO and throw strict, so an exception will never itself be bottom. Using throwIO' !e = throwIO e in the code above instead of throwIO allows the exception to be caught. A more conservative approach might be to just force result of toException before calling raise#, but this only works when users use an explicit type signature to fix the expression type, rather than an exception constructor. David

1 0

Deriving Data for poly-kinded datatypes
by Ryan Scott 24 Feb '17

24 Feb '17

Hi Pedro, I'm quite confused by a peculiarity of deriving Data (more info in Trac #13327 [1]). In particular, if you write this: data T phantom = T deriving Data Then the derived Data instance is NOT this: instance Typeable phantom => Data (T phantom) where ... But instead, it's this: instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f The gcast1 part is why it requires the stronger (Data phantom) context, as you noted in Trac #4028 [2]. What confuses me, however, is that is apparently does not carry over to poly-kinded datatypes. For instance, if you write this: data T (phantom :: k) = T deriving Data Then you do NOT get this instance: instance Data (phantom :: *) => Data (T phantom) where ... dataCast1 f = gcast1 f But instead, you get this instance! instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 This is quite surprising to me. I'm not knowledgeable enough about Data to know for sure if this is an oversight, expected behavior, or something else, so I was hoping you (or someone else highly knowledgeable about SYB-style generic programming) could help me out here. In particular: 1. Does emitting "dataCast1 f = gcast1 f" for datatypes of kind (k -> *) make sense? Or does it only make sense for types of kind (* -> *)? 2. Is there an alternate way to define dataCast1 that doesn't require the stronger Data context, but instead only requires the more general Typeable context? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13327 [2] https://ghc.haskell.org/trac/ghc/ticket/4028#comment:5

3 6

MSYS2 update (those who build on Windows please read)
by Phyx 24 Feb '17

24 Feb '17

Hi Windows devs, February comes with a major change in behavior for MSYS2/Cygwin. Tools such as awk/sed etc now use binary mode unless on a text mount: https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html This is problematic because GHC etc only use the underlying OS to determine how to output line endings. As such we output \r\n but in sed et al $ will no longer match line endings. Which means out scripts are currently broken. Do not upgrade your MSYS2 install until a workaround for this is in place or you will be unable to compile GHC. If you have updated your MSYS2 then using a text mount may be the easiest option to get a working build again. As it seems just downgrading the tools alone is not enough. Thanks, Tamar

1 1

Datacon RULES test
by David Feuer 24 Feb '17

24 Feb '17

For good or ill, Simon doesn't want RULES for datacons. T12689 has to be removed (leaving T12689a, which is still fine). But I don't know enough about what you're doing with T12689broken to know how to make it express the right idea after this change. Can you please advise? Thanks, David Feuer Well-Typed LLP

2 1

Windows build broken
by Simon Peyton Jones 22 Feb '17

22 Feb '17

Please please please could some one fix this? On windows. It's frustrating being unable to build. Please please Simon libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: Not in scope: data constructor FILETIME Perhaps you meant Win32.FILETIME (imported from System.Win32.Time) | 57 | FILETIME ft <- Win32.getSystemTimeAsFileTime | ^^^^^^^^

3 5

RE: Windows build broken
by Simon Peyton Jones 22 Feb '17

22 Feb '17

Re-adding ghc-devs. | Settup up things so that all master pushes go through a build&smoke-test-on- | all-relevant-platforms purgatory shouldn't be that problematic.. I know. We discuss it periodically The trouble is that it takes work to do these things (reliably, solidly) and everyone is busy. If someone felt able to step up to doing it, it'd be great. Simon | -----Original Message----- | From: Kosyrev Serge [mailto:skosyrev@ptsecurity.com] | Sent: 22 February 2017 14:18 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Windows build broken | | Simon, | | It pains me to see how something trivially preventable by a functioning | "continuous integration" setup keeps causing you trouble so regularly. | | Settup up things so that all master pushes go through a build&smoke-test-on- | all-relevant-platforms purgatory shouldn't be that problematic.. | | I know, it's not my ground to meddle in, but I just can't be calmly watching | this entirely preventable suffering.. | | Simon Peyton Jones via ghc-devs writes: | > Please please please could some one fix this? On windows. | > | > It’s frustrating being unable to build. | > | > Please | > | > please | > | > Simon | > | > libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: | > | > Not in scope: data constructor FILETIME | > | > Perhaps you meant Win32.FILETIME (imported from System.Win32.Time) | > | > | | > | > 57 | FILETIME ft <- Win32.getSystemTimeAsFileTime | > | > | ^^^^^^^^ | | -- | с уважениeм / respectfully, not a GHC developer at all, Косырев Сергей | -- | “Most deadly errors arise from obsolete assumptions.” | -- Frank Herbert, Children of Dune

1 0

Status of early-inline branch
by David Feuer 21 Feb '17

21 Feb '17

I've been working on trying to get the branch in shape for review and such, but I see that you're also still working on it. So we don't tread on each other's toes too much, I'm wondering if you could give me a sense of what the status is, which commits are firm and which you might change, etc. Thanks, David Feuer

2 2