Re: GHC 7.8 release?

We seem to be circling ever closer to consensus here! Yay! I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta: *Haskell Platform* comes out twice a year. It is based on very stable version of GHC, and intention is that people can just

Re: HP 2013.2 and GHC 7.6.2

Thanks for all the switft work. Here's my understanding of the situation: - 7.6.2 has a bug (#7748) in it, which also appears in a lesser form in 7.6.1. - SPJ has a fix, that works for the minimal code given in the bug report. - Others are now trying to verify it fixes the bug as it

Re: HP 2013.2 and GHC 7.6.2

in preference to a major bump to the latest-n-greatest. Let's try to keep this last minute bumping to a minimum! On Tue, Apr 16, 2013 at 5:17 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 April 2013 23:17, Mark Lentczner mark.lentcz...@gmail.com wrote: Thanks for all the switft work

Re: HP 2013.2 and GHC 7.6.2

Well based on Christian's excellent news, looks to mee like there is a candidate for a GHC-7.6.3. And so it sounds like that should pick up Cabal-1.16.0.3. I'd like to limit the micro-bumps as much as possible, is that it, everyone? ​ I'd also like to double confirm with all concerned that we

Re: small improvement to roles mechanism

Hello there all! Sorry I've been completely out of touch(*). If I have any hope of keeping Haskell Platform on track... or even slip by just a few weeks (say, no later than end of November)... then it seems impossible that GHC 7.8 would make a good candidate for the next HP release. Do I read

Wither Haskell Platform 2013.4.0.0

Friends — Deep apologies for being so out of touch the last two months(*). In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time: *1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is

Re: Wither Haskell Platform 2013.4.0.0

It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common

Re: Wither Haskell Platform 2013.4.0.0

Okay, now I'm confused What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options? ​ - Mark ___ ghc-devs mailing list ghc-devs@haskell.org

Simple script to make existing GHC or HP installation work with Xcode 5

Friends - I've developed a simple shell script that should enable your existing GHC 7. or HP installation work with Xcode 5. https://gist.github.com/mzero/7245290 Place that script somewhere, make it executable, and run it. *Then follow the instructions it tells you!* You will end up having to

Re: Another CPP gotcha for the manual

This does not appear to be the case, at least any more. The way GHC invokes gcc for c pre-processing only removes /*…*/ style comments, not the later // style: module Main where (//) :: Double - Double - Double a // b = a / b / b main = print $ 1 // 2 works: runhaskell -cpp CppTest2.hs 0.25

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 2

It looks like the Mac builds are specific to the version of Mac OS X they were compiled on. This is very unfortunate, as now we'll have to produce at least four variants of HP for each. The only thing holding back a build on either Maverricks or Mountain Lion (10.9 and 10.8) from working on 10.7

Re: We need to add role annotations for 7.8

Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. From a meaning perspective, I'm agnostic on the default. From a engineering perspective, I want a default that does a good enough, reasonably safe thing if

Re: We need to add role annotations for 7.8

Again, sorry for the 11:59 meddling The syntax of role annotations is very heavy weight, and requires lots of CPP where there wasn't need before. Two thoughts: 1) Couldn't we do something like use cue type constraints? For example, assuming the default is representational, and that phantom

Re: We need to add role annotations for 7.8

*Apologies* On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones simo...@microsoft.comwrote: The situation today is that · A client of a library can use GND to do bad things to the library (e.g. change the “key” type of (Map key value)). · Role annotations allow the library

Re: We need to add role annotations for 7.8

The first line was supposed to say: *Apologies for the delayed and multi-message response.* ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

building for Mac

When the bin-dists are built, can we have them built with a 10.6 or 10.7 target? If built that way, they should run on all greater OSes. I don't think there is a reason not to. The current bindists, built on Mavericks, seg fault 11 when run an 10.7 or earlier. - Mark

Re: building for Mac

This stackoverflow question seems to be the same issue: http://stackoverflow.com/questions/21676716/macos-compile-from-mavericks-lion-compatible-executable Also, minor but, Cabal docs (not the haddock, the user manual), didn't end up in the bindist. - Mark

Re: clang warnings

I'm the source of ghc-clang-wrapper. I can add -Qunused-arguments easily enough. I just last night ran across the spaces problem - and I'm not entirely sure the bug is in ghc-clang-wrapper! I'll investigate... turns out all you need to do is try to compile something that is in a directory with

cc ld extra flags

I'd like to build GHC, and all the base libs, with an extra flag supplied to cc (well gcc) and ld commands: I thought I could just add this to mk/build.mk: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 But this seems very inconsistently applied. For example:

Re: cc ld extra flags

After some deep investigation (including reading the clang source), turns out the easiest way is to just set an environment variable for the duration of the GHC configure/build sequence: export MACOSX_DEPLOYMENT_TARGET=10.7 ​Will do the right thing in all contexts throughout the build without

the case of the missing Cabal doc

In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark ___ ghc-devs mailing list ghc-devs@haskell.org

Re: the case of the missing Cabal doc

On Mon, Jun 30, 2014 at 1:25 PM, Ian Lynagh ig...@earth.li wrote: It was converted to markdown, and GHC's build system doesn't know how to build markdown docs. It's in libraries/Cabal/Cabal/doc/. Okay then... I can see how the GHC build doesn't want to depend on pandoc! I'll probably remove

Head's up, yall: Cabal's dir layout changed

I just noticed that the default directory layout that cabal uses (under .cabal) has changed between 1.16 and 1.18. In particular: In 1.16 -- libsubdir: $pkgid/$compiler -- datasubdir: $pkgid -- docdir: $datadir/doc/$pkgid in 1.18 -- libsubdir: $arch-$os-$compiler/$pkgid -- datasubdir:

Status of Haskell Platform 2014.2.0.0

The status is: *Good-to-Go!* The new-build branch of Haskell Platform is in pretty great shape: - One consistent build system using Shake - Builds source tarball - Builds linux distribution tarball - Builds Mac installer - Builds in one command line from a GHC bindist to end-user

Re: 7.8.3 source tarball imminent

Morning all. I've just kicked off the Mac builds Since I have several to do, and they take awhile... and I have to go to work today... I expect these to be ready sometime late tonight PST.​ - Mark ___ ghc-devs mailing list ghc-devs@haskell.org

gcc vs. clang builds of 7.8.3 on OS X

In building the OS X bindist for 7.8.3, I had to choose which of several ways to build it. In particular, I could build it with a newere Xcode, which uses clang, or an older Xcode which uses gcc. I decided to nofib benchmark the variations and see before I released. Here is what I found... I

Re: gcc vs. clang builds of 7.8.3 on OS X

I will try to measure on 10.7 later today. Preliminary numbers for gcc 4.9 are even better than clang - it saves 12% over gcc 4.2 builds. However, the gcc runtime isn't the same as the Apple standard... and we are so far at a loss how to package a ghc based on 4.9 that would work for Mac users

Re: gcc vs. clang builds of 7.8.3 on OS X

, Jul 12, 2014 at 9:04 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: I will try to measure on 10.7 later today. Preliminary numbers for gcc 4.9 are even better than clang - it saves 12% over gcc 4.2 builds. However, the gcc runtime isn't the same as the Apple standard... and we are so

Re: gcc vs. clang builds of 7.8.3 on OS X

The clang executable size mystery deepens: The sizes are indeed wy big: 7.4M test-files-clang/test* 4.5M test-files-clang/test-stripped* 1.4M test-files-gcc/test* 1.1M test-files-gcc/test-stripped* Looking at the load info from the stripped versions, it is all in the main text segment:

Re: gcc vs. clang builds of 7.8.3 on OS X

AHA! The clang libs weren't/aren't being built split-obj! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: gcc vs. clang builds of 7.8.3 on OS X

Found the culprit!!! XCodeVersion=`xcodebuild -version | grep Xcode | sed s/Xcode //` This line in configure doesn't work on a system that just the Xcode command line tools installed! It also won't work on an OS X system that has some other tool chain (say, via brew) installed. On such

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

If this is happening on OS X and your computer is really clang (gcc -version will say clang somewhere) ... then please try this simple fix: Edit the compiler settings file, find the line with Haskell CPP Flags, and add -P to the list of flags. If that works, then the upcoming Haskell

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

Glad that worked for you... I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. - Mark ​ ___ ghc-devs

updated OS X 7.8.3 bindist

The release 7.8.3 bindist for OS X was flawed: It was not build SplitObjs. That is my fault for not catching it before releasing it. You may demand a beer from me at ICFP as restitution I have built a new 7.8.3 bindist for OS X, and tested in 10.9, 10.7, and 10.6(!). It is SplitObjs, and

Re: Status of Haskell Platform 2014.2.0.0

As per comments: Done: - hashable can be bumped to 1.2.2.0. - network can be bumped to 2.4.2.3 - unordered-containers can be bumped to 0.2.4.0 - happy bumped to 1.19.4 - bump cabal-install to 1.18.0.5 ​Unsure: - Not sure if you want QuickCheck 2.7.5 rather than 2.6 -- cc'ing

Re: Status of Haskell Platform 2014.2.0.0

On Tue, Jul 15, 2014 at 12:25 PM, Matthias Kilian k...@outback.escape.de wrote: Apart from this, i guess future versions of attoparsec (and other libraries included in the HP) will probably depend on more libraries not yet in the HP. So what's the correct way to deal with this? - Use newer

Re: Status of Haskell Platform 2014.2.0.0

On Tue, Jul 15, 2014 at 1:59 PM, Bryan O'Sullivan b...@serpentine.com wrote: Well, it was rather late to hear that you weren't going to upgrade attoparsec, too ;-) On Sun, Mar 30, 2014 at 1:06 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: SO, In anticipation of releasing a HP shortly

Planning a Haskell Platfrom Release Candidate this weekend

Here's my remaining list before putting out a realse candidate. I'm aiming for this weekend: *-- General --* [ ] haddock linkage from HP packages to GHC core packages is broken [ ] decision on QuickCheck? *-- Source Tarball --* [ ] missing platform.sh scripts [ ] missing os-extras in hptool/src

The haddock / clang problem revisited ... root cause found...

tl;dr: - cabal is the culprit - If you have the `Extensions: CPP` directive in your .cabal file, then when invoking haddock, cabal causes every file to be pre-processed twice in sequence. - pre-processing isn't idempotent - when done under clang, it outputs things that ghc.

Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW?

On a related front... I don't have a talk to give (hence I didn't submit a proposal)... But I'd love it if some of us could have a group discussion about coordinating releases, and our approach to putting out Haskell: In short, we see it as several related peices (GHC, Cabal, Haddock, core libs,

Re: At long last: 2014.2.0.0 Release Candidate 1

On Thu, Jul 24, 2014 at 5:09 AM, George Colpitts george.colpi...@gmail.com wrote: Installed on the Mac, looks good, ... ​did cabal install -j3 of threadscope, criterion, hlint, ghc-mod, quickcheck, smallcheck and smartcheck​ That's all a good sign... not sure if following is significant:

Re: At long last: 2014.2.0.0 Release Candidate 1

On Thu, Jul 24, 2014 at 5:30 AM, Brandon Allbery allber...@gmail.com wrote: E. Whoever is making the Mac bindist should take care to avoid any MacPorts (or for that matter Homebrew) components slipping in to it; this will cause problems down the road. That would be makin' that bindist!

Re: At long last: 2014.2.0.0 Release Candidate 1

On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne svenpa...@gmail.com wrote: The source tarball is missing a few files for hptool: I'll try to catch them the next round... or pull requests on github welcome! On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne svenpa...@gmail.com wrote: ...But I'm a bit

Haskell Platform 2014.2.0.0 Release Candidate 3

Small update to the Haskell Platfrom 2014.2.0.0 release: We have new Release Candidate 3 versions of the source tarball... and a new generic-linux bindist of the platform! - source tarball: haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz

Release building for Windows

Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a

Re: Release building for Windows

Seems to me that given the state of affairs, it is best to just leave it as it is this round: That is GHC is built split-obj, but the HP libs on Windows are not. In general, split-obj only makes executables smaller at the expense of link time and memory. It is a trade-off, and I'd make the call

last call... for HP 2014.2.0.0

As it stands, I'm planning on calling the final RCs final: - RC2 Mac - RC4 Win - RC3 Src and linux-dist They have a few wibbles, but nothing close to show-stopping. I'll rebuild the web site and upload it tomorrow and announce then as well. - Mark (still on vacation) L.

MAC builds of 7.8.4 and 7.10.1 RC2

I have built in the official manner both GHC 7.8.4 and GHC 7.10.1 rc2 from sources. You can find them here: http://www.ozonehouse.com/mark/platform/ They need some doesn't crash out of the box testing on a few OS X systems before I think we should declare them good and put them on the download

Re: GHC support for the new record package

My 2¢ on this topic are solely about syntax: • I actually like the @ sigil: It is somewhat mnemonic: @age is like roughly at the age field... • The module import hacks are horrid for something so important to the evolution of the language. And it makes me cringe for every writer of a programmer

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

I've just built a bindist under 10.10, but just normal not expressly llvm. I'll test this in a bit then post it -- but might be sometime tomorrow before it is up. - Mark ​ ___ ghc-devs mailing list ghc-devs@haskell.org

Re: GHC support for the new record package

On Tue, Jan 27, 2015 at 3:47 PM, Edward Kmett ekm...@gmail.com wrote: We can make up our own combinators for putting these things together, but we can't use (.) from the Prelude or even from Control.Category. Is this the only reason *not* to have a data type? (Sorry, I wasn't totally

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

I will have 7.10 RC2 and 7.8.4 mac bindist up tonight - but I need help testing them on various configurations before we declare them good. I'll post again when they are up. - Mark ​ ___ ghc-devs mailing list ghc-devs@haskell.org

wither the Platform

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

Re: HP 2015.2.0.0 and GHC 7.10

On Mon, Mar 23, 2015 at 7:58 AM, Carter Schonwald carter.schonw...@gmail.com wrote: How do you get the ghc docs built successfully on os x? I've tried to replicate you buildsteps but docbook hits a failure when tryingto download some remote file. I added my OS X build notes for GHC

Re: HP 2015.2.0.0 and GHC 7.10

(copied below) - weigh in - short and sweet - if you have an opinion - if you have a spare Mac - download it and try it! http://www.ozonehouse.com/mark/platform/ Crazy, right? I know... but, can we do this? — Mark On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner mark.lentcz...@gmail.com wrote

Re: wither the Platform

On Tue, Mar 24, 2015 at 10:09 PM, Gershom B gersh...@gmail.com wrote: There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Actually, pretty much all other language systems (C++,

Re: wither the Platform

On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones simo...@microsoft.com wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:*

Platform 2015.2.0.0 Alpha 2 for debian based systems

I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for generic debian linux systems. It includes GHC 7.10.2, using the generic linux bindist. This is a tarball, not a package. Installation instructions: cd / sudo tar xvf ...downloaded-tarfile... sudo

Re: Platform 2015.2.0.0 Alpha 2 for debian based systems

I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for generic debian linux systems. It includes GHC 7.10.2 Ooops - GHC 7.10.1 - of course! ___ ghc-devs mailing list ghc-devs@haskell.org

Re: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2

Verfied that the upload of the ghc bindist was cut short. New upload in progress! I've double checked and the build of Platform, and it's upload is fine. ___ ghc-devs mailing list ghc-devs@haskell.org

Re: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2

Deep apologies to all. The full, correct, and sha-sum verified upload is now up: 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.bz2 - Mark On Sat, Mar 28, 2015 at 5:19 PM, Mark Lentczner mark.lentcz...@gmail.com wrote

Re: wither the Platform

On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel h...@gnu.org wrote: I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion

Re: HP 2015.2.0.0 and GHC 7.10

NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do

Re: wither the Platform

On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett ekm...@gmail.com wrote: The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great

Re: HP 2015.2.0.0 and GHC 7.10

version for 7.10.1 final Thanks again On Mon, Mar 23, 2015 at 2:13 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: 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

Re: HP 2015.2.0.0 and GHC 7.10

On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne svenpa...@gmail.com wrote: A +1 for including exceptions, but why version 0.6.1, which is quite old? I would propose including the latest and greatest 0.8.0.2 version. Ah - because gci 3001.2.2.0 has a bound on exceptions 0.7. John Chee: I don't

Re: HP 2015.2.0.0 and GHC 7.10

On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee cheech...@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

Re: [haskell-infrastructure] wither the Platform

On Mon, Mar 23, 2015 at 7:27 AM, Gershom B gersh...@gmail.com wrote: I thought the current language on the page was rather balanced? It leads any user away from the Platfrom: - From the homepage - Downloads from the top bar - First links are three OS links, click any one -

Re: wither the Platform

On Mon, Mar 23, 2015 at 3:20 AM, Thomas Miedema thomasmied...@gmail.com wrote: From the downloads https://www.haskell.org/ghc/download_ghc_7_8_4 page on the GHC homepage: Alas, that warning has never been effective. But it is moot anyway: Start from the shiny Haskell.org page and see where

Re: HP 2015.2.0.0 and GHC 7.10

On Mon, Mar 23, 2015 at 5:22 AM, Miëtek Bak mie...@bak.io wrote: Could you restore the OS X GHC 7.10.1-rc2 bindist? Didn't think anyone would want it now that we have RC3... I don't have it on the server anymore, but see you have it mirrored. Hashes are:

Re: HP 2015.2.0.0 and GHC 7.10

On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. Is soon measured in hours? If not - I

release timing

I'm wondering if ghc 7.10.2 has a rough time table yet? This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' heads up would be

Re: release timing

On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones simo...@microsoft.com wrote: *So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”.* Other things being equal, the longer we wait, the more fixes will be in. This seems like a pretty ad

Re: Time files... and here's another alpha HP for 7.10

There is now an OS X installer of this* pre 7.10.2 - we'll just call it alpha 3 *Platform, again, built with head of GHC 7.10 branch this morning: Haskell Platform 7.10.1.20150601 alpha 3 64bit.pkg

the platform has outgrown Travis-CI

I finally figured out what was wrong with the Travis CI build for Haskell Platform, and got it all working w/hvr's .debs of GHC (for the boot compiler)... and ran smack into this: Your test run exceeded 50 minutes. SO... I'd like to find another CI solution. Is phabricator.haskell.org an

Re: Time files... and here's another alpha HP for 7.10

When you did the cabal install of haddock, which haddock did you get? Isn't 2.16.0 the latest? And that should be what is in the Platform. I guess I should check that the haddock in GHC is actually 2.16.0! ​ ___ ghc-devs mailing list

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1

And the Windows install for HP 7.10.2 RC1 is out too: HaskellPlatform-7.10.1.20150612-x86_64-setup.exe http://www.ozonehouse.com/mark/platform/HaskellPlatform-7.10.1.20150612-x86_64-setup.exe 08c5f2168bdf9147b548263d2b45e1db6b602830002f27f92bf066b761f0

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1

Right on the heels of Austin's 7.10.2 RC1 announcement we have... *Haskell Platform 7.10.2 RC1 as well!* This is the same release of GHC 7.10.2 plus a 35+ common packages and tools for Haskell, pre-built and easily installable: generic linux:

Time files... and here's another alpha HP for 7.10

So - I hear from a bird that 7.10.2 might be just around the corner. I'm getting ahead of the curve! I just did a fully hermetic and clean build of head of GHC 7.10 branch (what should become 7.10.2), and then brought HP up-to-date: - bootstrapped with 7.10.1 (so hptool needed fixes to build

Re: Time files... and here's another alpha HP for 7.10

On Tue, Jun 2, 2015 at 4:40 AM, George Colpitts george.colpi...@gmail.com wrote: I guess I should file a haddock bug as I got the same error installing threadscope Does ghc --print-libdir display the correct path? (That is, with the full version number.) - Mark

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

In concert, Haskell Platform 7.10.2 RC2 is out (for OS X and Linux - Windows on its way). You can find it here: http://www.ozonehouse.com/mark/platform/ Only minor changes since RC1: - version bumps to hashable, HTTP, OpenGLRaw, and cabal-install - closed issues #160 (typography), #157

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

OS X GHC build has these test failures: Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) rtslinker_unload [bad exit code]

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

And now Windows RC2 for Haksell Platform is also here: http://www.ozonehouse.com/mark/platform/ [1008] : sha256sum HaskellPlatform-7.10.1.20150630-x86_64-setup.exe 6157bbb50de63c1af068f83c4b7888f12b6f29d258bf33dbefb56dd6ea717021 HaskellPlatform-7.10.1.20150630-x86_64-setup.exe​

Re: Improving the Get Haskell Experience

I'm glad to read the variety of response, and want to summarize and respond to the most common points: *stack is too new * *having two package managers will confuse* — It is indeed new, though it has arrived very well formed, and has gained a lot of users in short order. There are two reasons

Re: Request to reopen the issue of 7.8 on El Capitan

I can build a 7.8.5 binary for release if someone can put the patch in the GHC tree. (Having a soft spot in my heart for the 7.8 line!) I'm leaving on a short trip, and will be back on Tuesday and build middle of next week. ​ - Mark ___ ghc-devs mailing

"Excuse me, I think this i my stop..." - Resigning from the Platform

I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all

Re: Improving the Get Haskell Experience

No - we are not talking about the upcoming, 7.10.2 HP release. It would for the next major release after that. Yes, stack has only been out ~1 month, but it has already shown traction in the community, and it has a clear working solution for managing curated pacakge sets, like Haskell Platform. ​

Improving the Get Haskell Experience

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of getting Haskell, including Haskell

A modest proposal (re the Platform)

Looks like GHC 7.8 is pretty near release. And while I know that we really like to have a GHC out for a while, and perhaps see the .1 release, before we incorporate it into the Platform, this GHC, while including many new and anticipated things, seems pretty well hammered on. Combine that with

Re: A modest proposal (re the Platform)

A few specific points: 1) 2013.4.0.0 isn't really "ready to be pushed" - there were delays, and then some rolling updates... and some churn. While there is a proposed set of packages... and it does compile... there is still some work on the Mac version (it needs to incorporate my patch script for

Re: We need to add role annotations for 7.8

Speaking from the vantage point of platform This pair of comments (emphasis mine) have my alarm index on high: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell wrote: > I'm quite worried about this change though. I thought the default rolefor > data type was nominal, as

Re: We need to add role annotations for 7.8

On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery wrote: > No; if the default is representational, everything works as it did in > earlier versions, potential bugs/unsafety and all. If the default is > immediately switched to nominal, *then* every affected type must be >