- ghc-devs - Haskell.org

GHC Weekly News - 2015/03/24
by Austin Seipp 25 Mar '15

25 Mar '15

(This post is available online with hyperlinks at https://ghc.haskell.org/trac/ghc/blog/weekly20150324) Hi *, It's time for the GHC weekly news. We've had an absence of the last one, mostly due to a lot of hustle to try and get 7.10 out the door (more on that shortly throughout this post). But now we're back and everything seems to be taken care of. This week, in the wake of the GHC 7.10 release (which is occuring EOD, hopefully), GHC HQ met up for a brief chat and caught up: - This week GHC HQ met for only a very short time to discuss the pending release - it looks like all the blocking bugs have been fixed, and we've got everything triaged appropriately. You'll hopefully see the 7.10 announcement shortly after reading this. We've also had small amounts of list activity (the past 6-8 weeks have been very, very quiet it seems): - Your editor sent out a call for developers to fill information in on the Status page about what they plan to do. If you're working on something, please add it there! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008661.html - Herbert Valerio Riedel asked about a possible regression regarding identifiers containing unicode subscripts - but nobody has replied! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008503.html - Doug Burke chimed in as a new contributor and wrote down some notes on what it took to write his first patch and submit it to us - and we really appreciate the feedback, Doug! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008526.html - Yitzchak Gale revived a thread he started a while back, which puttered out: bootstrapping GHC 7.8 with GHC 7.10. The long and short of it is, it should just about work - although we still haven't committed to this policy, it looks like Yitz and some others are quite adamant about it. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008531.html - Neil Mitchell uncovered a nasty bug in GHC 7.10.1 RC3, submitted it to us. He also wrote a fantastic [http://neilmitchell.blogspot.co.at/2015/03/finding-ghc-bug.html blog post explaining the issue]. And it was promply diagnosed, fixed, and taken care of by our own Joachim Breitner. Thank you for the fast response Joachim and Neil! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008532.html - Mark Lentczner has announced Alpha releases of the Haskell Platform 2015.2.0.0, containing GHC 7.10.1 RC3: https://mail.haskell.org/pipermail/ghc-devs/2015-March/008597.html - Simon Peyton Jones asks: what's the current state about having simultaneous installations of a package? Simon is a bit confused as to why this is still a problem when we have all the tools to solve it, it looks like! (But read on for more): https://mail.haskell.org/pipermail/ghc-devs/2015-March/008602.html - Michael Snoyman asks: can we get a new feature patch in GHC 7.10.2? The answer seems to be an unfortunate 'no', but with some tips, Michael may end up backporting the changes from HEAD to GHC 7.10 himself. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008612.html Some noteworthy commits that went into `ghc.git` in the past two weeks include: - Commit 71fcc4c096ec0b575522e4c2d0104ef7a71a13c5 - GHC defaults to using the `gold` linker on ARM/Android and ARM/Linux targets. - Commit 9dfdd16a61e79cb03c633d442190a81fe5c0b6b8 - Bump `ghc-prim` to version 0.4.0.0. - Commit 42448e3757f25735a0a5b5e2b7ee456b5e8b0039 - GHC HEAD now always looks for LLVM 3.6 specifically. Closed tickets this past week include: #9122, #10099, #10081, #9886, #9722, #9619, #9920, #9691, #8976, #9873, #9541, #9619, #9799, #9823, #10156, #1820, #6079, #9056, #9963, #10164, #10138, #10166, #10115, #9921, #9873, #9956, #9609, #7191, #10165, #10011, #8379, #10177, #9261, #10176, #10151, #9839, #8078, #8727, #9849, #10146, #9194, #10158, #7788, #9554, #8550, #10079, #10139, #10180, #10181, #10170, #10186, #10038, #10164, and #8976. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Note: please write down your tentative plans for GHC 7.12
by Austin Seipp 24 Mar '15

24 Mar '15

Hi *, I plan on shipping GHC 7.10.1 Real Soon Now (a bit later today). In light of this - we should think about what we want to get done for 7.12! I've set up a new status page about GHC 712. It's got a lot of tickets on it; I'll probably prune them later: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1 At the top, you can see a list of tentative plans for what we want to implement. This list is short and I'm surely missing some things (for example - Edward, what might be on the Backpack roadmap? Worth mentioning?) Please feel free to add to this list liberally - I'll be reusing it for the 2015 HCAR, which will be due in a month or so. Thanks all, and happy hacking. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

hackage statistics
by Meng Wang 24 Mar '15

24 Mar '15

Hi All, A few of us are writing a survey of FP and would like to include some statistic graphs of Haskell (similar to those found here:http://galois.com/blog/2009/03/one-million-haskell-downloads/) Does anyone know how I can obtain such data? Thank you very much, Meng

2 1

build system/default targets question
by Tamar Christina 24 Mar '15

24 Mar '15

Hi All, I'm trying to figure out the build system, but can't figure out why this isn't working: In the driver folder I created a new folder "ghc-split". The content of that is: -rw-r--r-- 1 Tamar Users 784 Mar 22 13:18 ghc.mk -rw-r--r-- 1 Tamar Users 513 Mar 15 11:40 ghc-split.cabal -rw-r--r-- 1 Tamar Users 1611 Mar 15 07:30 LICENSE -rw-r--r-- 1 Tamar Users 2162 Mar 15 07:51 Main.lhs -rw-r--r-- 1 Tamar Users 518 Mar 22 11:45 Makefile My Makefile contains: dir = driver/ghc-split TOP = ../.. include $(TOP)/mk/sub-makefile.mk and my ghc.mk: driver/ghc-split_USES_CABAL = YES driver/ghc-split_PACKAGE = ghc-split driver/ghc-split_dist-install_INSTALL = YES driver/ghc-split_dist-install_PROGNAME = ghc-split driver/ghc-split_dist-install_INSTALL_INPLACE = YES driver/ghc-split_dist-install_WANT_BINDIST_WRAPPER = YES $(eval $(call build-prog,driver/ghc-split,dist-install,0)) From https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/StandardT… I gather that this should work under the standard target make all_driver/ghc-split_dist-install, however when I do a make I get: make[2]: *** No rule to make target 'all_driver/ghc-split'. Stop. Makefile:72: recipe for target 'all_driver/ghc-split' failed make[1]: *** [all_driver/ghc-split] Error 2 make[1]: Leaving directory '/home/Tamar/ghc2' ../../mk/sub-makefile.mk:45: recipe for target 'all' failed make: *** [all] Error 2 and I haven't been able to figure out why.. Any thoughts? Regards, Tamar

2 1

Re: wither the Platform
by davean 24 Mar '15

24 Mar '15

> > I didn't have that problem with Python or Clojure. I didn't run into > it with Python until I was building enterprise-class systems. I ran > into other issues that made me drop Clojure before I ran into this > one. > Well, it also was standard python practice to monkey patch the libraries to fix deficiencies, like the inability to call "PUT" with the standard HTTP lib. Where as I see people picking the right X library to have a style of programming that makes their code easy to follow in Haskell instead of "just making it work". Now I probably see a highly non-random selection of programmer's work in Haskell. I'd say what I see is not what you propose at all though. I see 2 or 3 HTTP client libs used in the same (large-ish) project even, because each of them has different code it makes easier and prettier. One of Haskell's attraction to me is the work done in selecting good abstractions and approaches to problems refining the method used. This will inherently lead to diversity. Sometimes its bad. but its part of not just getting the job done, but instead trying to do it better.

1 0

Re: wither the Platform
by Neil Mitchell 23 Mar '15

23 Mar '15

On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart. Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. I can get up to the platform with one invoke of cabal, and if someone decides to require a new network, it just works. I think the Platform now gives a worse user experience on Windows, so the ideas (or names) probably need migrating around. Thanks, Neil On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus <apfelmus(a)quantentunnel.de> wrote: > Mark Lentczner wrote: >> >> 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? > > > Thanks a lot for your hard work on the platform! > > I myself am an avid user of the platform (OS X), because for me, it's the > easiest way to install Haskell on a new machine; I just did so the other > day. > > The only time when the platform seems to be a handicap is when a new version > of GHC is being released and I would have to update my packages. Usually, I > don't test them with the new version and rely on pull requests instead. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

6 7

fast test suite failures on OS X with 7.10 RC head
by Carter Schonwald 23 Mar '15

23 Mar '15

hey all heres the results from the test suite run on a build of 7.10 head on OS X i believe that some of the test suite failures are because I set the min OS X version to 10.6 rather than 10.7, and that some are because GCC (unlike clang) doesn't support certain OS X specific things like objective C or related header files. I'll add more information as I have the time, but figured I should share this for now Unexpected results from: TEST="T10019 sigcabal01 objc-hi objcpp-hi retc001 linker_unload debug T2276_ghci T9203 T1969 T9675 T783 T5642 T6048" OVERALL SUMMARY for test run started at Sun Mar 22 14:58:07 2015 EDT 0:31:34 spent to go through 4405 total tests, which gave rise to 18027 test cases, of which 13966 were skipped 52 had missing libraries 3950 expected passes 45 expected failures 0 caused framework failures 0 unexpected passes 8 unexpected failures 6 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_compile debug [bad stderr] (normal) driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) driver/retc001 retc001 [bad stderr] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) rts linker_unload [bad exit code] (normal) th T10019 [bad stdout] (ghci) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9675 [stat not good enough] (optasm) perf/should_run T9203 [stat too good] (normal) ~/D/r/g/testsuite (ghc-7.10|…) $ echo $MACOSX_DEPLOYMENT_TARGET 10.6

3 2

Re: [haskell-infrastructure] wither the Platform
by Gershom B 22 Mar '15

22 Mar '15

Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines. A) Users that sandbox and users that do not. B) Libraries that maintain HP compatibility and libraries that do not. The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes — platform-installed packages being available in sandboxes and causing trouble. However, the current solution we push to new users is lacking in certain ways. In particular, I really don’t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc. Furthermore, it is _very_ important to have some community process to “bless” or suggest some set of packages from the zoo of hackage as the “typical” way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc. Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes. Overall I tend to agree with dons’ comments on the reddit thread (http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) and think the key idea is to preserve _both_ the “one stop installer” aspect of the platform and the “blessed package set” element, but to decouple them from one another. This leads to the following proposals: 1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place. 2) For generic linux point to both ghc and cabal binaries from the core teams. 3) Continue to pick out and list a compatible, “blessed” set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains. 4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes. And of these I have one outstanding question — while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can’t solve that, then the MinGHC approach doesn’t yet provide a strictly better solution. Cheers, Gershom On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale(a)sefer.org) wrote: > Mark Lentczner wrote: > > 1) Abandon the Platform… > > > > 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. > > I vote for (3) but in a way that it would *not* be much work. > We should definitely do the Platform, but with much *less* work. > > The most important reason we need the Platform is as > a default selection of quality basic libraries. We should not abandon > that concept. Curated package sets do not replace that - the > Platform is not just packages that build together. Nor do OS > packagers. The platform is a community-wide set of basic default > packages that are mature, well tested, all work together well, > and stable. > > The second most important role of the Platform is a web site > where you can get a clear picture of how to download and install > a default Haskell installation for your platform, and a simple view > of where we are in the parade of releases. That should also continue. > > The hardest work of the Platform was its role as a way to bootstrap a > Haskell installation. That is what made it so hard for HP to keep up > with GHC releases, and what consequently gave people the impression > that HP is always old. That work doesn't need to be done as part of the > Platform anymore. We should leverage other good work people are > doing to create installers, and stop doing it as part of the HP process. > > The most important part of an HP release should be a cabal package > that provides the packages in the platform, at the right versions, with > a specification of the recommended GHC version as a pre-requisite. > > Perhaps we can also provide an HP-branded slick installer for some > platforms that does everything in one click, built as a thin wrapper of > some existing installer. But that should not delay the official release > of an HP version. It's just a nice-to-have extra. > > Once we pare down the work needed for an HP release, we should > release new versions of HP quite often - *more* often than GHC > releases, not less often. > > Another thing we should fix is the (now false) impression that HP > gets in the way of installing other packages and versions due to > cabal hell. We should make "require-sandbox" the default setting > in the cabal config file. I would go further - I would add a cabal > feature to create a sandbox automatically unless "--user" or > "--global" is specified explicitly. I would make "foo installed" a > default constraint (that is easy to override) for all platform packages, > which solves virtually all cabal hell problems (assuming you are > using a sandbox) and will not keep things old if we release often. > > Thanks, > Yitz > _______________________________________________ > haskell-infrastructure mailing list > haskell-infrastructure(a)community.galois.com > http://community.galois.com/mailman/listinfo/haskell-infrastructure >

2 1

can't run validate on OS X for 7.10 head branch!
by Carter Schonwald 22 Mar '15

22 Mar '15

hey everyone! error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] is the key bit, seems like apple clang bundled with xcode 6 doesn't have that option thoughts? (do we need to do some auto conf magic to support more clang variants?) this gist provides a bit more context https://gist.github.com/cartazio/ac04ab8048c9f7577d3d thanks! -Carter

2 1

Re: wither the Platform
by Mark Lentczner 21 Mar '15

21 Mar '15

Eeek! I really really did mean to make the subject *whither*, not *wither!*

2 1