March 2015 - ghc-devs

GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2
by Mark Lentczner 28 Mar '15

28 Mar '15

I have built the 7.10.1 bindist for OS X. It is currently sitting on my server at: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.10.1-x86_64-apple-darwin.tar.…> \O/ I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202015.2.0.0%20a…>. It is based on the above bindist. I should have an ubuntu version of the Platform built by tomorrow. \O/ - Mark *sha256 sums:* c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee ghc-7.10.1-x86_64-apple-darwin.tar.bz2 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg

2 1

Re: HP 2015.2.0.0 and GHC 7.10
by Mark Lentczner 28 Mar '15

28 Mar '15

Thanks, John! Alpha 2 is now out: - github commit <https://github.com/haskell/haskell-platform/commit/fa90210b908e26616904d8f0…> - OS X Build: Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202015.2.0.0%20a…> Notable changes: - Based on GHC 7.10.1 release - updated attoparsec - updated cgi - brand spanking new major release of OpenGL & GLUT (and related packages) - brand new primitive - updated vector - modern exceptions - updated cabal-install - added ObjectName, StateVar, and transformers-compat, needed by the above Whew! I'll be building the ubuntu based generic build tonight (just got a brand new Intel NUC for this!) Keep the cards and letters coming! Test it out! Review the versions! *Look over the issues list on GitHub <https://github.com/haskell/haskell-platform/issues>, and see if there is anything we need to fix before going final sometime in the next few days.* - Mark

1 0

Re: HP 2015.2.0.0 and GHC 7.10
by Mark Lentczner 28 Mar '15

28 Mar '15

On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee < cheecheeo(a)gmail.com> wrote: > Mark: I'm bumping the dependency on exceptions now. I'll post back before > noon PDT if I get a release out. > Rockin'! All: I appreciate the crazy weekend scramble! Alas, for me during the week I'm swamped with work (a good thing - it means my project there is going very well!) If this sync'ing with GHC releases path is well received, then next time we'll have a bit more (~1 month) runway! - Mark

1 0

HP 2015.2.0.0 and GHC 7.10
by Mark Lentczner 28 Mar '15

28 Mar '15

I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: - *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here! The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! If you want to poke at it, the source is in the pre-release branch at GitHub <https://github.com/haskell/haskell-platform/tree/pre-release>, and the OS X builds are at my usual platform staging area: Index of /mark/platform <http://www.ozonehouse.com/mark/platform/> Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! - Mark

11 23

Re: [commit: ghc] master: Rename driver phases C(obj)cpp to C(obj)cplusplus (abde5da)
by Karel Gardas 27 Mar '15

27 Mar '15

Hi Thomas, Cplusplus is quite long identifier, bad for eyes. Usually in C++ community if you can't use cpp then you use cxx. It's shorter and clear even when reading fast, don't you think? Karel PS: of course even before cxx it was CC, but I think this does not have any advantage over cxx in this context... On 03/27/15 09:38 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/abde5da4dee5f3b83264f8471e458b20d… > >> --------------------------------------------------------------- > > commit abde5da4dee5f3b83264f8471e458b20d04f8b29 > Author: Thomas Miedema<thomasmiedema(a)gmail.com> > Date: Fri Mar 27 21:37:49 2015 +0100 > > Rename driver phases C(obj)cpp to C(obj)cplusplus > > Before: > Cpp = Pre-process C > Ccpp = Compile C++ > Cobjcpp = Compile Objective-C++ > CmmCpp = Pre-process Cmm > > Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and > `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for > `pre-processing` throughout the compiler. > > Reviewed By: austin > > Differential Revision: https://phabricator.haskell.org/D756 > > >> --------------------------------------------------------------- > > abde5da4dee5f3b83264f8471e458b20d04f8b29 > compiler/main/DriverPhases.hs | 32 ++++++++++++++++---------------- > compiler/main/DriverPipeline.hs | 9 +++++---- > ghc/Main.hs | 2 +- > 3 files changed, 22 insertions(+), 21 deletions(-) > > diff --git a/compiler/main/DriverPhases.hs b/compiler/main/DriverPhases.hs > index 2433f6d..2d7d904 100644 > --- a/compiler/main/DriverPhases.hs > +++ b/compiler/main/DriverPhases.hs > @@ -111,10 +111,10 @@ data Phase > | Cpp HscSource > | HsPp HscSource > | Hsc HscSource > - | Ccpp > - | Cc > - | Cobjc > - | Cobjcpp > + | Ccplusplus -- Compile C++ > + | Cc -- Compile C > + | Cobjc -- Compile Objective-C > + | Cobjcplusplus -- Compile Objective-C++ > | HCc -- Haskellised C (as opposed to vanilla C) compilation > | Splitter -- Assembly file splitter (part of '-split-objs') > | SplitAs -- Assembler for split assembly files (part of '-split-objs') > @@ -148,10 +148,8 @@ eqPhase (Unlit _) (Unlit _) = True > eqPhase (Cpp _) (Cpp _) = True > eqPhase (HsPp _) (HsPp _) = True > eqPhase (Hsc _) (Hsc _) = True > -eqPhase Ccpp Ccpp = True > eqPhase Cc Cc = True > eqPhase Cobjc Cobjc = True > -eqPhase Cobjcpp Cobjcpp = True > eqPhase HCc HCc = True > eqPhase Splitter Splitter = True > eqPhase SplitAs SplitAs = True > @@ -163,7 +161,9 @@ eqPhase CmmCpp CmmCpp = True > eqPhase Cmm Cmm = True > eqPhase MergeStub MergeStub = True > eqPhase StopLn StopLn = True > -eqPhase _ _ = False > +eqPhase Ccplusplus Ccplusplus = True > +eqPhase Cobjcplusplus Cobjcplusplus = True > +eqPhase _ _ = False > > -- Partial ordering on phases: we want to know which phases will occur before > -- which others. This is used for sanity checking, to ensure that the > @@ -189,10 +189,10 @@ nextPhase dflags p > LlvmMangle -> As False > SplitAs -> MergeStub > As _ -> MergeStub > - Ccpp -> As False > + Ccplusplus -> As False > Cc -> As False > Cobjc -> As False > - Cobjcpp -> As False > + Cobjcplusplus -> As False > CmmCpp -> Cmm > Cmm -> maybeHCc > HCc -> As False > @@ -215,13 +215,13 @@ startPhase "hscpp" = HsPp HsSrcFile > startPhase "hspp" = Hsc HsSrcFile > startPhase "hc" = HCc > startPhase "c" = Cc > -startPhase "cpp" = Ccpp > +startPhase "cpp" = Ccplusplus > startPhase "C" = Cc > startPhase "m" = Cobjc > -startPhase "M" = Cobjcpp > -startPhase "mm" = Cobjcpp > -startPhase "cc" = Ccpp > -startPhase "cxx" = Ccpp > +startPhase "M" = Cobjcplusplus > +startPhase "mm" = Cobjcplusplus > +startPhase "cc" = Ccplusplus > +startPhase "cxx" = Ccplusplus > startPhase "split_s" = Splitter > startPhase "s" = As False > startPhase "S" = As True > @@ -247,9 +247,9 @@ phaseInputExt (Hsc _) = "hspp" -- intermediate only > -- because runPipeline uses the StopBefore phase to pick the > -- output filename. That could be fixed, but watch out. > phaseInputExt HCc = "hc" > -phaseInputExt Ccpp = "cpp" > +phaseInputExt Ccplusplus = "cpp" > phaseInputExt Cobjc = "m" > -phaseInputExt Cobjcpp = "mm" > +phaseInputExt Cobjcplusplus = "mm" > phaseInputExt Cc = "c" > phaseInputExt Splitter = "split_s" > phaseInputExt (As True) = "S" > diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs > index 24df3a2..845cc95 100644 > --- a/compiler/main/DriverPipeline.hs > +++ b/compiler/main/DriverPipeline.hs > @@ -1068,7 +1068,7 @@ runPhase (RealPhase Cmm) input_fn dflags > -- way too many hacks, and I can't say I've ever used it anyway. > > runPhase (RealPhase cc_phase) input_fn dflags > - | any (cc_phase `eqPhase`) [Cc, Ccpp, HCc, Cobjc, Cobjcpp] > + | any (cc_phase `eqPhase`) [Cc, Ccplusplus, HCc, Cobjc, Cobjcplusplus] > = do > let platform = targetPlatform dflags > hcc = cc_phase `eqPhase` HCc > @@ -1137,9 +1137,9 @@ runPhase (RealPhase cc_phase) input_fn dflags > > ghcVersionH<- liftIO $ getGhcVersionPathName dflags > > - let gcc_lang_opt | cc_phase `eqPhase` Ccpp = "c++" > + let gcc_lang_opt | cc_phase `eqPhase` Ccplusplus = "c++" > | cc_phase `eqPhase` Cobjc = "objective-c" > - | cc_phase `eqPhase` Cobjcpp = "objective-c++" > + | cc_phase `eqPhase` Cobjcplusplus = "objective-c++" > | otherwise = "c" > liftIO $ SysTools.runCc dflags ( > -- force the C compiler to interpret this file as C when > @@ -1176,7 +1176,8 @@ runPhase (RealPhase cc_phase) input_fn dflags > else []) > > -- GCC 4.6+ doesn't like -Wimplicit when compiling C++. > - ++ (if (cc_phase /= Ccpp&& cc_phase /= Cobjcpp) > + ++ (if (cc_phase /= Ccplusplus&& > + cc_phase /= Cobjcplusplus) > then ["-Wimplicit"] > else []) > > diff --git a/ghc/Main.hs b/ghc/Main.hs > index da95ebf..a95382f 100644 > --- a/ghc/Main.hs > +++ b/ghc/Main.hs > @@ -653,7 +653,7 @@ doMake srcs = do > haskellish (f,Nothing) = > looksLikeModuleName f || isHaskellUserSrcFilename f || '.' `notElem` f > haskellish (_,Just phase) = > - phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcpp, CmmCpp, Cmm > + phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcplusplus, CmmCpp, Cmm > , StopLn] > > hsc_env<- GHC.getSession > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits >

1 0

ANNOUNCE: GHC version 7.10.1
by Austin Seipp 27 Mar '15

27 Mar '15

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

wither the Platform
by Mark Lentczner 27 Mar '15

27 Mar '15

I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: *1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. *3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? — Mark

24 59

RE: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers
by Yongqian Li 27 Mar '15

27 Mar '15

Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored...

2 2

Fwd: [hackage-server] Duplicate anchors in source code (#319)
by Eric Crockett 26 Mar '15

26 Mar '15

I reported a bug in HsColour ( https://github.com/haskell/hackage-server/issues/319#issuecomment-76088047) which has been fixed in a new version. The HSColour dev thought it might be useful to mention this new version of HsColour to the GHC devs so that documentation for 7.10 will be marginally easier to reference. -Eric

1 0

quick report using GHC 7.10 RC3
by Mark Lentczner 26 Mar '15

26 Mar '15

I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... — Mark

4 3