- ghc-devs - Haskell.org

PrimRep constructor Vec
by Richard Eisenberg 03 Feb '16

03 Feb '16

Hi Geoff, I'm working on the fix for #11471, which involves interacting with the PrimRep type. (You don't need the ticket background to understand this question, though.) One of PrimRep's constructors is VecRep, which Simon tells me is your domain. The problem is that I can find nowhere in the source code where this constructor is used. I see several consumers, but no producers. Is this constructor now unused? Should I remove it? Thanks, Richard

3 3

Re: Adding a "release" setting in build.mk.sample (and some other build system questions)
by Harry . 03 Feb '16

03 Feb '16

> https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build flavour isn't used for the release build?

3 3

Re: [GHC] #11526: unsafeLookupStaticPtr should not live in IO
by Mathieu Boespflug 02 Feb '16

02 Feb '16

IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. Sent from my mobile. I'll have a look at the new material on the wiki shortly. It would be nice to close out the basic distributed story.

2 1

Best practices for merging?
by Geoffrey Mainland 02 Feb '16

02 Feb '16

I've been away from GHC for a while, and it's not clear to me what the best practices for merging are now. My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward. This lets me look at the repo history and easily see where a feature branch landed and get a good idea of what changes it contains. I have used this approach in the past with GHC, e.g., SIMD support and typed TH. For smaller sets of changes, I might skip the merge commit, but I still break up my changes into discreet bits, which helps anyone reading the change set to see what's going on. It seems the current policy is to submit changes via Phab and then, after approval, squash everything into a single patch and apply it with arc. At least that is my reading of https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews. Is that what I should be doing? For feature branches, is that also what is advised? Thanks, Geoff

10 19

[ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1
by Ben Gamari 02 Feb '16

02 Feb '16

The GHC Team is very pleased to announce the first release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide can be found at http://downloads.haskell.org/~ghc/8.0.1-rc1/ This is the first in a series of release candidates which will allow us to get wider testing of the significant changes that have occurred since the 7.10 series. These include, * the TypeInType extension, which unifies types and kinds allowing for promotion of more Haskell constructs to the type-level * the introduction of type application in source programs * support for recursive superclass relationships * support for Applicative do notation * introduction of the DuplicateRecordFields language extension * a rewritten and substantially more thorough pattern match checker * the introduction of injective type classes * introduction of the Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * the ability to run the GHCi interpreter in a separate process, allowing a callstacks in GHCi, easier integration with tooling, and more and much more. Changes of this magnitude will invariably bring bugs. This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon, * The new -XInjectiveTypeFamilies language extension will likely be renamed to -XTypeFamilyDependencies * #11120: Type representations are missing for some types and promoted constructors * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails * #11276: Pattern checker performance can degrade significantly in presence of pattern matches with guards * #11405: Type-level skolem-escape check fails incorrectly * #11414: Use of -XStrict results in compiler abort * #11379: Instance solver fails to terminate * #11419: Haddock documentation is currently not included in the binary distributions (and hence is missing on downloads.haskell.org) * #11370: -Wredundant-constraints being included in -Wall breaks the three-release compatibility policy In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page [2]. If you have a ticket that you would like to see addressed that does not meet one of these criteria, please bring this to our attention. Likewise, if you encounter an issue please open a ticket if one does not already exist. Also note that we currently cannot offer 32-bit Windows builds due to breaking changing in a recent Windows 10 upgrade. We'll work to resolve this before the 8.0 release but please let us know if this poses a significant problem for you. Cheers, - Ben [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

13 35

Dropping bzip2 release tarballs?
by Ben Gamari 02 Feb '16

02 Feb '16

tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? If so, let us know! Hello everyone, As you may have noticed, a few releases ago we started producing xz-compressed binary distributions in addition to the usual bzip2 tarballs. While preparing 8.0.1-rc1 it was suggested that we move to distributing xz tarballs exclusively. Not only would this move reduce storage and bandwidth demands on our infrastructure but it would also simplify the job of producing the distributions. Indeed there is plenty of precendent for projects who have moved exclusively to xz (the Linux kernel and git being two examples). Of course, these reasons alone aren't sufficient to abandon those who might rely on our bzip2 tarballs. If you feel strongly that we should continue to distribute bzip2 tarballs, please let us know. Thanks! - Your friendly GHC packaging gnomes

4 4

Build failing
by Simon Peyton Jones 02 Feb '16

02 Feb '16

A clean Windows build fails. See below. help! Simon rts\Linker.c:444:7: error: error: pointer type mismatch in conditional expression [-Werror] : pinfo->owner->fileName ^ rts\Linker.c:429:7: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 4 has type 'void * const' [-Werror=format=] "GHC runtime linker: fatal error: I found a duplicate definition for symbol\n" ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:254: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 /cygdrive/c/code/HEAD$

3 3

Nailing down what we expect IO to do and not do - and why
by Christopher Allen 01 Feb '16

01 Feb '16

I'm writing a book, I'd like to get this nailed down and to get it right. If anyone on here that's familiar with the various ways in which IO/State#/realWorld# work in GHC and you have time to reply, anything at all would be welcome. Any pointers, links, references, details, anecdotes, or faint memories of GHC bugs will be greatly appreciated! Getting this written up (possibly for addition to Michael Snoyman's wiki article?) would make me, and I imagine others, a lot happier with trying to understand how the different bits and bobs fit together. I will be dumping my notes as I don't want to get linked to stuff that can be googled because I've already lost 10-15 hours to just that in the past 3-4 days. Digging it up in the compiler is hard because compiler behavior that influences how IO actions are treated don't necessarily have "IO" or "realWorld" mentioned in the relevant parts of the compiler, optimizations, etc. What I'm hoping for is answers on what specifically preserves the listed properties we want from IO in the compiler, prims, or structure of how we write IO actions. What we expect IO to do: - Disable sharing of results, even when it's not a lambda and is evaluated multiple times by the same name. ie, getCurrentTime :: IO UTCTime should get evaluated more than once. - Not reorder sequential IO actions, such as in a do-block. Called "linearity" below - Not duplicate the effects of IO actions. Effects shouldn't be spuriously duplicated during optimization passes. - Effects should not be discarded separately of the value returned by an IO action, merged, or elided. # Sharing A friend suggested that perhaps one-shot semantics via the state hack for State# in the IO type is responsible for disabling sharing, I don't believe so, but here are my notes. >-fno-state-hack >Turn off the "state hack" whereby any lambda with a State# token as argument is considered to be single-entry, hence it is considered OK to inline things inside it. This can improve performance of IO and ST monad code, but it runs the risk of reducing sharing. >A one shot lambda >State hack, makes the lambda over State# assume it's one-shot universally by default. >one-shot/state hack is an anti-inlining heuristic, suggesting that inlining is costly. Also I found this on Trac, does anyone know the answer to this? Is the summary above accurate? >Can the IO state hack be avoided if oneShot is used in the right places in library code, e.g. in IO’s definition of >>=? This seems related how the state token works, for differentiating which IO action is which and how many times an IO action should run, when it should run, etc. >From the prims: >data State# s >State# is the primitive, unlifted type of states. It has one type parameter, thus State# RealWorld, or State# s, where s is a type variable. The only purpose of the type parameter is to keep different state threads separate. It is represented by nothing at all. >data RealWorld >RealWorld is deeply magical. It is primitive, but it is not unlifted (hence ptrArg). We never manipulate values of type RealWorld; it's only used in the type system, to parameterise State#. # Linearity Is this from the nesting of lambdas? It doesn't seem like that's enough based on the various examples using State/State# in GHC Trac bug tickets. The RealWorld token seems to be what's driving this but precisely how that works hasn't been easy to find. # Discarding, not inlining effects I believe these are addressed by has_side_effects in the prim ops. I could very well be wrong. can_fail has_side_effects Discard NO NO Float in YES YES Float out NO NO Duplicate YES NO * Duplication. You cannot duplicate a has_side_effect primop. You might wonder how this can occur given the state token threading, but just look at Control.Monad.ST.Lazy.Imp.strictToLazy! We get something like this p = case readMutVar# s v of (# s', r #) -> (S# s', r) s' = case p of (s', r) -> s' r = case p of (s', r) -> r I believe duplication addresses inlining IO actions more generally but I could be wrong. Here's a note I found regarding elision/merging: * Use the compiler flag @-fno-cse@ to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like @test@ in the example below). Any help or pointers for nailing down and documenting this would be greatly appreciated. Also if there's a more detailed explanation of what behavior is expected out of each unsafe function, that would help as well. There are bits and pieces I've been able to aggregate from the GHC trac tickets. References used (not exhaustive): - Referential Transparency; Haskell Wiki https://wiki.haskell.org/Referential_transparency - IO Inside; Haskell Wiki https://wiki.haskell.org/IO_inside - Unraveling the mystery of the IO Monad; Edward Z. Yang http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the-io-monad/ - Evaluation order and state tokens; Michael Snoyman https://wiki.haskell.org/Evaluation_order_and_state_tokens - Haskell GHC Illustrated; Takenobu Tani - Tackling the Awkward Squad; Simon Peyton Jones http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/… - Note [IO hack in the demand analyser]; GHC source code - Monadic I/O in Haskell 1.3; Andrew D. Gordon and Kevin Hammond - Haskell Report 1.2 http://haskell.cs.yale.edu/wp-content/uploads/2011/01/haskell-report-1.2.pdf Thank you for your time, Chris

2 2

[ANNOUNCE] Shaking up GHC
by Andrey Mokhov 31 Jan '16

31 Jan '16

Dear GHC developers, I am happy to announce that the Shaking up GHC project has finally reached the first milestone. The goal of the project is to design a new GHC build system based on Shake that will eventually replace the current make-based one. See the project page for more details: https://github.com/snowleopard/shaking-up-ghc. There is still a long way until we can match the capabilities of the current build system. At the moment we only build vanilla way. Validation, documentation, build flavours and cross-compilation are not yet implemented. Known limitations are listed here: https://github.com/snowleopard/shaking-up-ghc#current-limitations. The purpose of this announcement is to attract alpha testers and collect early feedback across multiple platforms and build configurations. We already have several success reports on Linux, OS X, Solaris and Windows. However, things will inevitably break and we hope to catch and fix as many of these cases as possible with your help. The instructions on how to try the new build system can be found here: https://github.com/snowleopard/shaking-up-ghc#your-first-build. We plan to be ready to become a part of the GHC tree around 1 March 2016, and catch up with the make build system around 1 June 2016. The dates are tentative and depend on how much time it takes us to resolve the remaining issues: https://github.com/snowleopard/shaking-up-ghc/milestones. I would like thank everyone who contributed to this project so far: Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the idea and guided me throughout the project; Moritz Angermann, Ben Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell contributed to the codebase. Thank you all! Kind regards, Andrey

4 8

Build broken
by Geoffrey Mainland 30 Jan '16

30 Jan '16

I attempted to rebase my fix for #11487, but I can no longer validate. The culprit is 6c7760b2. I am seeing the errors below under linux, building with 7.10.3. Herbert, I hope there is a quick fix? Thanks, Geoff libraries/unix/System/Posix/IO/Common.hsc:316:61: error: • Couldn't match type ‘()’ with ‘Base.CFLock’ Expected type: Ptr Base.CFLock Actual type: Ptr CFLock • In the third argument of ‘Base.c_fcntl_lock’, namely ‘p_flock’ In the second argument of ‘throwErrnoIfMinus1_’, namely ‘(Base.c_fcntl_lock fd (5) p_flock)’ In a stmt of a 'do' block: throwErrnoIfMinus1_ "getLock" (Base.c_fcntl_lock fd (5) p_flock) libraries/unix/System/Posix/IO/Common.hsc:364:61: error: • Couldn't match type ‘()’ with ‘Base.CFLock’ Expected type: Ptr Base.CFLock Actual type: Ptr CFLock • In the third argument of ‘Base.c_fcntl_lock’, namely ‘p_flock’ In the second argument of ‘throwErrnoIfMinus1_’, namely ‘(Base.c_fcntl_lock fd (6) p_flock)’ In the expression: throwErrnoIfMinus1_ "setLock" (Base.c_fcntl_lock fd (6) p_flock) libraries/unix/System/Posix/IO/Common.hsc:371:35: error: • Couldn't match type ‘()’ with ‘Base.CFLock’ Expected type: Ptr Base.CFLock Actual type: Ptr CFLock • In the third argument of ‘Base.c_fcntl_lock’, namely ‘p_flock’ In the second argument of ‘throwErrnoIfMinus1_’, namely ‘(Base.c_fcntl_lock fd (7) p_flock)’ In the expression: throwErrnoIfMinus1_ "waitToSetLock" (Base.c_fcntl_lock fd (7) p_flock)

1 0