- ghc-devs - Haskell.org

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

27 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

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