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 https://github.com/haskell/haskell-platform/blob/pre-release/notes/building-ghc-os-x to the Platform repo. Enjoy! - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
*Hey you* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day? I know, I know, our process is long and full of discussion, and hard, and slow let's smash that, eh? How'z'bout it? OKAY? Good! Your task is: - look over the the source file at GitHub https://github.com/haskell/haskell-platform/blob/pre-release/hptool/src/Releases2015.hs that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (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: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
Gershom B gersh...@gmail.com: On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (c...@cse.unsw.edu.au) wrote: Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn’t use sandboxes either.) Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even “stronger” sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir! Then, I don’t understand why the Platform isn’t the recommended this is what you install if you don’t know better on the homepage. The mistake here is to try to make this a one-size-fits all. I honestly don’t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. .. Well, we have got people who want to learn Haskell now and who use Haskell as part of their coursework now. Why make them wait for future work which will probably take longer than planned, needs to be rolled out, etc? I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them “the downloads page gives you options, pick the platform option.” Nobody who wants to use the platform must wait for anything. Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. I know, but look at the subject of this message (and the original post in this thread). Mark’s questions was —as I read it— do we still need the platform. Then, lots of power users jumped up and down criticising the flaws in the platform and why other approaches are better. To which I say, other approaches are better for you (plural)[1], but not to a large class of novices. That is all. Also, to reiterate, I’m arguing with you because you replied to my message. I definitely do appreciate all the effort you (and others) are putting into the homepage and infrastructure. Manuel [1] English is such an awkward language :P We just want to recognize that this other set of users — those coming from other languages, and wanting to “from the gate” install large sets of dependencies — this set of users has grown and is growing and if we don’t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a “power user” and manage lots of dependencies with abandon you may want the minimal installers, and if you want “a good, wide-ranging set of defaults to experiment and learn with” then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don’t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! 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. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! Beyond that I don’t feel we’re discussing anything as metaphysical as flexibility or simplicity. And I don’t feel my own preferences are necessarily better or worse than others — I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is
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++, Java(*), Python, PHP, Ruby, Scala, etc...) meet *all* users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: *The problem is how GHC is released:* It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. *This is an insufficient set of things for most users.* At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
2015-03-25 7:31 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] look over the the source file at GitHub that defines the release see if the version of your stuff looks right The OpenGLRaw and GLUTRaw versions are OK, for OpenGL and GLUT we should use newer versions I just released (OpenGL-2.12.0.0 and GLUT-2.7.0.0). These contain much requested API additions/generalizations. Furthermore, due to other popular requests like generalizing things and making OpenAL stuff independent from OpenGL, I split off improved StateVar (thanks to Edward Kmett!) and ObjectName packages again, which are now additional dependencies. This move was made in spite of all those bikeshedding discussions around them, because several actual package users requested them. (Listen to your customers!) I simply don't want to be held back by eternal theoretical discussions anymore, instead let's ship what people actually want. [...] look near the end where there is a bunch of stuff I kinda just added to get it all to compile [...] As mentioned above, we need StateVar-1.1.0.0 and ObjectName-1.1.0.0 now, too. 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. rantRegarding the random packages: Shipping 2 packages for basically the same thing is silly IMHO and a bad sign for something which claims to be a coherent set of APIs. Either these packages should be merged or the dependencies adapted. Offering choice for the same task has no place in the platform IMHO, we should ship what is considered the best/most widely used for each area. For the more arcane needs, there's always Hackage.../rant ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: wither the Platform
Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: · There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. · But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. · The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That’s why GHC’s download page explicitly says “Stop! Shouldn’t you be installing the Haskell Platform instead?”. · HP releases should therefore, in contrast to GHC releases, be widely publicised. · Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a naïve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that “the GHC and the Platform release are one and the same”. I think of the HP release as the “real GHC release”. It’s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. 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: · Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn’t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. · Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: · Is the original plan still good? · Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it’s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B gersh...@gmail.commailto: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++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. This is an insufficient set of things for most users. At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!)
Re: HP 2015.2.0.0 and GHC 7.10
cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: *Hey you* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day? I know, I know, our process is long and full of discussion, and hard, and slow let's smash that, eh? How'z'bout it? OKAY? Good! Your task is: - look over the the source file at GitHub https://github.com/haskell/haskell-platform/blob/pre-release/hptool/src/Releases2015.hs that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (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: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On 2015-03-25 at 06:52:22 +0100, Mark Lentczner wrote: On Tue, Mar 24, 2015 at 8:20 PM, Gershom B gersh...@gmail.com wrote: install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. That sounds like a recipe for Cabal Hell, Platform or not! Regardless of the hellish issue, Gershom's comment indirectly highlights of one thing where I'm wondering if the HP's growth isn't bounded by diversity: There are some areas which I'd expected to some degree in a batteries-included platform, where the Haskell ecosystem has diverged into popular but distinct package-sub-ecosystems (which all have their respective communities/followers), such as HTTP-serving (Yesod/Snap/Happstack/...), or which lens-abstraction to use, or at the more fundamental level, even the streaming abstraction (pipes/conduit/io-streams/machines/...) doesn't seem to have a clearly recommended and agreed upon representative. Also, to this day we don't have any TLS library support in the platform, which also is subject to debate of which crypto-library to use (and there's also the question whether to use OpenSSL via FFI or a native TLS reimpl). So the platform-included `HTTP` package is not even able to access `https://` URLs which is quite sad, as this also holds back `cabal-install`'s ability to access `https://`-only repositories. So, where do you see the platform's growth for those packages/areas where you'll probably not get a reasonable majority consensus for picking a specific package? Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote: [...] • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. [...] I guess the solution is to release a new version of HP. IMHO, if HP releases are to happen more frequently, a simple way to upgrade would be desirable rather than having to download a new multi-MiB full installer image each time only because a single package was updated (and the ability to have access to multiple HP releases side-by-side -- in case that isn't supported already) Or put differently, how shall HP users be informed they're not running the latest HP version with all known critical bugs fixed? Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Wed, Mar 25, 2015 at 11:10 AM, Herbert Valerio Riedel h...@gnu.org wrote: Or put differently, how shall HP users be informed they're not running the latest HP version with all known critical bugs fixed? While I can see most of the problems people claim the platform has, this particular one is shared by manual installs of packages. Cabal prefers installed version, so a package with a bug will not automatically be upgraded, and there is no warning informing users either. Erik ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: wither the Platform
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:m...@mired.org] Sent: 25 March 2015 09:30 To: Simon Peyton Jones Cc: Mark Lentczner; Gershom B; Manuel M T Chakravarty; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@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. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
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 m...@mired.org wrote: On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones simo...@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 librar...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
Simon Peyton Jones simo...@microsoft.com: 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: · Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn’t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. · Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. I’d say, both. Re 1, a big part of the problem is the whole cabal, package dependency and versioning morass. Re 2, I think, there are multiple factors. The delays in putting out the HP (as previously mentioned). Power users reading GHC Status reports and wanting to get the goodies as quickly as possible. The HP just being quite a bit of hard work people like to avoid. Manuel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in RC until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go release in the same announcement. *In fact, let's version HP with the same number as GHC!* *Pare the Platform Back:* Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. *And, make that stuff be the latest it can be at each release. *The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. *Make sure the Platform Installers are Complete:* I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. *Make Updating the Packages in Cabal 'work':* I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. *One Web Site:* Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community hath spoken recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Wed, Mar 25, 2015 at 10:24 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. OpenGL has always been an odd fit; it was included partly because of the size and complexity to build, but also because it was felt that batteries-included had to include *some* kind of graphics library. I'm inclined to think that it doesn't really belong in the core Platform, myself. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Wed, Mar 25, 2015 at 10:47 AM, Mike Meyer m...@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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On 25-03-2015 15:24, Mark Lentczner wrote: Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in RC until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go release in the same announcement. *In fact, let's version HP with the same number as GHC!* What is the purpose of doing this? It's not clear to me that there's any upside, only the rather large downside of GHC HQ (and thus some of us downstreams) having to wait arbitrarily long for the HP release. The historical record for timeliness of HP releases is not encouraging. Are we just expecting that the HP will somehow magically attract more developers... which will somehow translate into more timely releases? Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between latest and greatest and batteries included. While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction. Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to step up: The research community will need to accept a more structured deployment of their innovations. Howard From: Mark Lentczner mark.lentcz...@gmail.com Sent: Wednesday, March 25, 2015 7:24 AM Subject: 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: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in RC until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go release in the same announcement. In fact, let's version HP with the same number as GHC! Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community hath spoken recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org
Re: HP 2015.2.0.0 and GHC 7.10
On Mon, Mar 23, 2015 at 4:35 AM, Sven Panne svenpa...@gmail.com wrote: 2015-03-23 6:13 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] exceptions multipart - needed by cgi - is exceptions now subsumed by something in transformers? [...] Coincidentally, Edward Kmett pointed me to the exceptions package while I was trying to generalize some of my packages from using plain IO to MonadIO. Alas, the transformers package still doesn't subsume the exceptions package, but IMHO it really should. Looking at the import list of e.g. Control.Monad.Catch alone is already indicating that. :-) transformers remains rather rigidly locked into Haskell 98/2010. mtl uses comparatively few extensions. exceptions uses rank-3 types in the API, which is something we currently don't do in transformers or the mtl. BTW: System.Console.Haskeline.MonadException has something similar, but far less complete, too, but that's really a strange place for such a feature. How did it end up there? Haskeline makes a few weird choices. e.g. The opacity of the InputT type pretty much renders the library very difficult to use the moment you need to do something that the package doesn't anticipate, like work with InputT in a transformer and expect any instances to exist, handle exceptions around _it_ in turn, lift monad transformers over it yourself, etc. =( I have more code for working around this aspect of Haskeline than I do for working with it. But it appears, in this case, Judah needed it for working with InputT, and chose to implement that by lifting transformer-by-transformer, since internally InputT is made by wrapping up an mtl-based type in a newtype. -Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
Thanks for doing this, AFAIK there is no bindist for 7.10.3 on the Mac. I downloaded and installed it, works great. I used it to install hlint and criterion. The only issue I saw was that uninstall didn't remove ghc executables of older versions that I had in /usr/local/bin (earlier bindist of 7.10.1rc2). Looking forward to using next 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 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
