March 2015 - ghc-devs

Re: wither the Platform
by Brandon Allbery 25 Mar '15

25 Mar '15

On Wed, Mar 25, 2015 at 10:47 AM, Mike Meyer <mwm(a)mired.org> wrote: > The words "Core Platform" makes me think there ought to be a "non-Core" > platform. This would actually match the Clojure model, where there's "the > stuff that's part of Clojure", "a set of recommended libraries", and "the > library archive anyone can put stuff in". If the platform is going to > undergo serious shrinkage, maybe the things that get pushed out - like the > OpenGL stuff - should be considered for that middle category? Less rigorous > testing, not bundled with the platform, but unlike all of hackage, an > effort is made to insure that there's a repository where it builds on top > of the "core platform"? > That's pretty much what I'm thinking of, yes. Not sure about "less rigorous testing" --- but "doesn't have to release at the same time" is a possibility. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

RE: wither the Platform
by Simon Peyton Jones 25 Mar '15

25 Mar '15

Very good! This one is perhaps a missing piece, if you are saying that a Windows user cannot use GHC without MSYS: • On Windows, it does not provide a complete environment (missing MSYS). On the other hand these three are examples of HP getting in the way: • By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. • The choice of package versions conflicts with the needs of many commonly used packages. • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. My question was: can they be fixed so that HP does not get in the way? E.g. if we solve the multiple-versions-of-packages problem with Cabal (which Duncan in a separate thread says we can), then that would solve the first two; and for the third, I guess the solution is to release a new version of HP. Simon From: Mike Meyer [mailto:mwm@mired.org] Sent: 25 March 2015 09:30 To: Simon Peyton Jones Cc: Mark Lentczner; Gershom B; Manuel M T Chakravarty; haskell-platform(a)projects.haskell.org; haskell-infrastructure(a)community.galois.com; Duncan Coutts; ghc-devs(a)haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons: Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform: • On Windows, it does not provide a complete environment (missing MSYS). • By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. • The choice of package versions conflicts with the needs of many commonly used packages. • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded.

3 2

Re: wither the Platform
by Michael Snoyman 25 Mar '15

25 Mar '15

Thanks for linking to that Mike, I'd actually forgotten that I'd written that :). Those are all very concrete issues people run into with the platform regularly, but I'd like to point out a meta issue: the platform tries to do too much, and in a non-composable manner. As I pointed out previously, it's providing a tools installer, choosing blessed libraries, pegging certain library versions, and selecting a distribution manner for those libraries. Even if the other issues were all addressed, I still believe the current trajectory of the platform is problematic, because it is necessarily removing choice. When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in my mind at least) was to allow individual tools to target individual goals. I don't expect every use case to be served by a curated package set (like LTS), so making that an optional feature of tooling makes sense. Similarly, almost all users (excepting some people playing with bleeding-edge GHC) will benefit from having an easy-to-use GHC+cabal-install installation, but a large set of users (specifically Hackage package authors) need a way to compile against different versions than the HP-blessed ones for testing purposes. And now a completely separate point: the current functioning of the HP process seems very much at odds with the way people actually write and release packages. Some examples: * Having to go through an extra step of requesting that a package version is bumped is tedious, and resulted in a buggy attoparsec being released in HP * Requiring package authors to endure long debate periods before the package is accepted scares people off from wanting to participate * A number of months back, the HP was used as a vehicle to push the PVP agenda as well, which completely alienated some people from wanting to participate (ironically, the package being pushed instead was not PVP compliant either, go figure). The practical result to that is we currently have no plans at all for getting TLS/HTTPS support into the platform, and everyone's tooling (cabal-install) is far less secure than it should be. * Authors want the freedom to quickly release new versions to their users, especially for bug fixes. While in theory the HP is set up to do bugfix releases, in practice this has never happened. In that sense, it is often preferable from the eyes of a package author *not* to have his/her package in the HP, as then users are better served As long as I'm writing a long email, I want to point out one other thing. A lot of the points being raised in this thread are discussing an idealized view of what the HP could become. I'm fully in favor of improving it (like I said, that's why I tried working with Mark on GPS Haskell and integrating with Stackage). However, we need to accept the reality of the situation today. Could the windows HP installer be improved like MinGHC to include MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work around the global package database issues we've been mentioning? Yes, and I support such moves. But we need to acknowledge current deficiencies, and plot out a course of action to solve them. And given that this thread started by lamenting how much effort the platform currently takes to maintain, I'm concerned about those improvements actually occurring. On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer <mwm(a)mired.org> wrote: > On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones <simonpj(a)microsoft.com > > wrote: > >> So that was the plan. I still think it’s a good plan. But it clearly >> is not working well, and I’m hazy about why. Possible reasons: >> > > Possibly relevant is the stackage commentary on HP at > http://www.stackage.org/install#why-not-haskell-platform: > > • On Windows, it does not provide a complete environment (missing MSYS). > • By placing a large number of packages in the global package database, > Haskell Platform installations are more easily corrupted. > • The choice of package versions conflicts with the needs of many commonly > used packages. > • Some of the package versions included with the platform have known and > severe bugs, and cannot be reliably upgraded. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

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