Re: wither the Platform
On 2015-03-25 at 15:24:30 +0100, 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!* [...] I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, while penalising those users that have no interest to use the HP anyway. Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) -- hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel h...@gnu.org wrote: I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion is to ensure that there is a consistent way for the community to get Haskell (as GHC itself is not enough for anyone - you need cabal at the least, and there are libraries that are common enough to be considered essential: text, vector, etc...). It is also to ensure there is a consistent reference point for package developers to test their packages against, for those packages that wish to support more than just the current GHC. Again, GHC releases themselves do not form a big enough reference point to ensure two packages that support the last two release are supporting the same thing. ... Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Well - if there is a week of commits to GHC, it should really do another RC before declaring it final. The difference between the last RC and the release should a single commit of no more than the version number change and the change log. Frankly, if we are all on board with this, then GHC could suffer a few day (week at most) delay between such an RC (as in we're frozen, save for the version stamp), and announcing release. This would not only allow there to be a Platform on the same day - but also GHC bindists for other OSes on the same day. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. We need to have to maintainers of the packages in the HP on board with this and down with the we're all going to gear up in the four weeks before a GHC version... not we'll gear up in the four weeks after. Frankly, for the kinds of packages that are in the platform (text, vector, unordered containers, etc...), having these packages lag GHC release so that they are broken on Hackage the day of GHC release is in nobody's interest: It gives a poor experience for ALL users of Haskell. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. But that is true of GHC as well. We need to stop having the attitude of Platform is for newcomers / GHC is for heavyweights. It is perfectly fine to announce GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible. Then our recommendations on to users on IRC are about which version is best for their needs, not don't install platform, you won't be able to get lens to compile... So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) People who care about stability will go ahead and hang back to what they consider a stable reference for them. (Gosh, how many projects are still supporting Python 2.6?!). But it will only be a stable reference if people use it, and package maintainers support it. Today's mess of GHC releases, Platform releases, alternative installer releases, etc... leaves both users and package maintainers no way to create or find stability. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: But that is true of GHC as well. We need to stop having the attitude of Platform is for newcomers / GHC is for heavyweights. It is perfectly fine to announce GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible. Then our recommendations on to users on IRC are about which version is best for their needs, not don't install platform, you won't be able to get lens to compile... The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. -Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett ekm...@gmail.com wrote: The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. Excellent! None taken. I appologize for my poor choice of example. Several people have included lens in an example of newcomers want to install x, y, and z - and it won't work with the platform. It is great that lens is not the problem - but it does underscore that the other packages haven't seen fit to match the same stability release points as lens - hence the unlikeliness of them working together except at HEAD. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: wither the Platform
Good plan. You didn’t mention a key point: · Make sure that installing the Platform doesn’t get in the way, if you subsequently want to upgrade libraries or whatever. I am un-clear about precisely what the problem(s) is/are here. I’m pretty sure they require infrastructure work (in Cabal) to achieve. Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 25 March 2015 14:25 To: Simon Peyton Jones Cc: 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 2:09 AM, Simon Peyton Jones simo...@microsoft.commailto: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
| 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.) I'm not sure that's true. We try hard not to break backward compatibility with new features. So a new GHC/HP release might have new features in GHC that are simply un-exploited by the HP libraries. That's fine! By far the biggest backward-compat issues are related to changes in the libraries themselves, rather than new features. Simon ___ 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: 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: 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 http
Re: wither the Platform
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! 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. 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 right for _them_. As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. Best, Gershom ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On 23 March 2015 at 15:01, Mark Lentczner mark.lentcz...@gmail.com wrote: On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones simo...@microsoft.com wrote: Like Richard, I was astonished by this. I always thought that the Haskell Platform was the route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine! I do too...! But follow the new Haskell.org pages like you are a user just want to install Haskell... you'll never end up with the Platform. Separate from any opinions about what's best going forward, chiming in on a bit of history for the new homepage, my motivations were: I wanted newbies to come to the site and find a download page *within the Haskell.org site* (not going to another site with a different design) that gives them something current and usable. I added the manual GHC install guide (now gone) because that is the method I was most familiar with. I've never used a HP release. So I surveyed the current crop of handy installers and judged community use of these things from mailing lists, reddit, IRC, etc. I saw enough interactions with newbies that the HP was not being recommended anymore due to its old GHC version and old packages (at the time of making that change on the page, the current HP release was very old), and the problem of the global database and installing new things. I'm not really familiar with the user experience of this, but people don't seem to like it. So the Linux install became recommendations of OS-specific installers (e.g. the Ubuntu and Arch repos are often recommended), and Windows remained HP coupled with the new MinGHC (which I also saw being recommended), and OS X became linked to the GHC for Mac OS X project (again, I saw people were using that), each of which claim superiority for various platform-specific reasons over the HP releases. So that's the decision-making process that went into making the page flow like it is. Someone added this text: Many now recommend just using a bare compiler combined with sandboxed dependencies, especially for new users. However, others prefer to start with the curated blessed set of packages in the Haskell Platform, which is available for Windows, OS X, and Linux. Which adds choice to users ill-equipped to make choice. I didn't add it (although I understand the motivation behind it). From a web site perspective, I'd prefer the download pages just be on the site. If it's these platform-specific installers, the HP, or some new helpful installer + LTS or whatever, it should be just there under /downloads, /downloads/windows, etc. and there should ideally be one, good, current choice. The current page is a compromise, not the final product. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Mar 23, 2015, at 10:58 AM, Christopher Done chrisd...@gmail.com wrote: Someone added this text: Many now recommend just using a bare compiler combined with sandboxed dependencies, especially for new users. However, others prefer to start with the curated blessed set of packages in the Haskell Platform, which is available for Windows, OS X, and Linux. Which adds choice to users ill-equipped to make choice. Your point here is a good one. I have to confess I'm not even sure, exactly, what combined with sandboxed dependencies means. (Use a sandbox for every package I wish to install, bypassing `cabal install`? Use a sandbox for every package I write? Use a sandbox to write Hello, world!? And what about GHCi?) And I'm not a newcomer to Haskell! This is not welcoming, in my opinion. If the recommended installation mentions sandboxes, it's the wrong recommendation, and we should aim for better. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Mon, Mar 23, 2015 at 3:20 AM, Thomas Miedema thomasmied...@gmail.com wrote: From the downloads https://www.haskell.org/ghc/download_ghc_7_8_4 page on the GHC homepage: Alas, that warning has never been effective. But it is moot anyway: Start from the shiny Haskell.org page and see where you land! ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery allber...@gmail.com wrote:
On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:
- It's always out-of-date. This statement, while true, isn't a direct
indication that something is wrong.
Perception is reality. The period when the Platform went without an
update for over a year because we were waiting on ghc 6.8.3 did a lot to
ruin the Platform's reputation.
I hate to bring this up, but it's not just a historical issue. The version
of attoparsec used by the platform today forces an old version of aeson to
be used (0.6.2.1). The combination of that aeson and attoparsec version is
vulnerable to an incredibly severe DoS attack for specially crafted JSON
strings (e.g., {foo:1e1000}). In fact, just a few
weeks ago I sent a private email to someone about a massive vulnerability
in a service (obviously not going to point out which one).
Michael
___
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-22, at 15:59, Michael Snoyman mich...@snoyman.com wrote: 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. I’d be very happy to contribute to this effort. In fact, I’ve already spent some of time addressing these issues. Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs — on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap. Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time…) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager. Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages -- Miëtek https://mietek.io smime.p7s Description: S/MIME cryptographic signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
From the downloads https://www.haskell.org/ghc/download_ghc_7_8_4 page on the GHC homepage: Version 7.8.4 (released December 23rd 2014) Stop! For most users, we recommend installing the Haskell Platform http://hackage.haskell.org/platform/ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. On Mon, Mar 23, 2015 at 11:01 AM, Simon Peyton Jones simo...@microsoft.com wrote: I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: Like Richard, I was astonished by this. I always thought that the Haskell Platform was *the* route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine! Let’s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to “How do I install GHC?”. It may be that the HP formula needs re-visiting, but I think it’s very important that we continue to give a very simple (click here) answer to that question. Simon *From:* Libraries [mailto:libraries-boun...@haskell.org] *On Behalf Of *Mark Lentczner *Sent:* 21 March 2015 17:54 *To:* ghc-devs@haskell.org; Haskell Libraries; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com *Subject:* wither the Platform I'm wondering how we are all feeling about the platform these days I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second 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? — 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
I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: Like Richard, I was astonished by this. I always thought that the Haskell Platform was the route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine! Let’s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to “How do I install GHC?”. It may be that the HP formula needs re-visiting, but I think it’s very important that we continue to give a very simple (click here) answer to that question. Simon From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Mark Lentczner Sent: 21 March 2015 17:54 To: ghc-devs@haskell.org; Haskell Libraries; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com Subject: wither the Platform I'm wondering how we are all feeling about the platform these days I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second 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? — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. Can we just include this fix into the platform installers? Yes. MinGHC was an experiment in seeing if we could do a Windows installer that worked with Network. We can, so the platform should. However, MinGHC has a few other advantages. It provides a switcher so you can put all the switchers on your PATH and type minghc-7.8.3 to get that version of GHC selected. Again, the platform could gain that feature. MinGHC also ships with GHC 7.2, 7.4, 7.6 and 7.8. Hopefully as soon as 7.10 is out within days we'll have a MinGHC for it. I'd also really like to start shipping MinGHC installers for GHC release candidates and even nightly GHC release candidates. As Mark says, the Platform has decent automated build test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to min vs max installers. Indeed, it has nothing to do with how many packages are shipped. As long as my installer ships with enough to install the packages I care about, then I don't care about min vs max. That said, all I really care is what GHC the platform includes, everything else is redundant (to me). As such having a link to a platform with each GHC version would be handy. Thanks, Neil ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Sun, 2015-03-22 at 09:17 +, Neil Mitchell wrote: 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. Can we just include this fix into the platform installers? As Mark says, the Platform has decent automated build test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to min vs max installers. Duncan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
Richard: The problem isn't the age itself, but rather the compatibility problems that age introduces. It can be quite difficult as a new user to get all of the libraries you want to use to play well with the platform. There's usually a way to make it work if you know what you're doing, but the platform is largely targeted at those who don't. This is particularly bad because library compatibility problems are inherently annoying to solve, or at least they feel that way to me. I think Gershom framed the problem well. From the discussion, it sounds like there are a lot of potential solutions, mostly in the category of re-conceive the platform. On Mon, Mar 23, 2015 at 9:32 AM, Miëtek Bak mie...@bak.io wrote: On 2015-03-22, at 15:59, Michael Snoyman mich...@snoyman.com wrote: 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. I’d be very happy to contribute to this effort. In fact, I’ve already spent some of time addressing these issues. Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs — on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap. Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time…) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager. Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages -- Miëtek https://mietek.io ___ 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 Sat, 2015-03-21 at 10:54 -0700, 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. There was a big argument about this. I was on the loosing side. :-) 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. I think it is worth it, and the issues that people are complaining about wrt the platform vs minimal installers can be fixed. 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. Right, I think there's still a great deal of value in having a simple recommendation for new users. One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised. 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: Well, the people who like it don't really complain. But yes, things need improving. *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. I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together. We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often. On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict. But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset). Duncan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
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. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
I also thought about it recently. IIRC ghc can already deal with any number of stacked package dbs; we only need to expose this somehow through cabal. On 22/03/15 11:52, Herbert Valerio Riedel wrote: On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: [...] 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. [...] Thoughts? My biggest complaint about the current HP is that it pollutes the global package database with additional packages which leak into `cabal sandbox`es. This causes `cabal sandbox` to provide quite different sandbox environments for HP environments compared to a non-HP environment without those additional packages pre-installed. Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes? Cheers, hvr ___ 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
On 21/03/2015, Mark Lentczner mark.lentcz...@gmail.com wrote: I'm wondering how we are all feeling about the platform these days I say leave it to the operating system distributions. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
It should go without saying that the first sentiment we all likely have is gratitude for all the work Mark has put into the platform, as well as all of the other contributors and maintainers the platform has had over the years. It hasn't just been work on producing the platform itself, but also for setting up an expectation in the Haskell world for high quality, reliable libraries. Even if the current incarnation of the platform is in jeopardy, I hope that we continue with that attitude going forward. I spend a lot of time working on Stackage, and obviously there's quite a bit of overlap between Stackage, Haskell Platform, and LTS Haskell. For purposes of this discussion, I think it's important to separate out different features of the platform, and see how we may continue or discontinue each individually: 1. A quality-approved set of libraries. As I see it, the process of coming up with recommended libraries can continue completely independently of any other work. 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. And as we've already discussed in the past regarding GPS, there's definitely room to add *more* to the platform with better build dependency solving. LTS Haskell was specifically an effort to try to advance that aspect of GPS. Putting this together, I think it leads to a new approach for the platform: minimalistic installers, curated package sets (ala LTS), recommended packages (ala the current platform set), and a robust means for installing these (e.g., cabal sandboxes). The Haskell world has advanced since the initial HP work, maybe all that's needed now is upgrading to the newest tooling available. I realize I haven't put down any concrete next steps here. I definitely have more ideas than I could put into this (already quite long) email. I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. On Sat, Mar 21, 2015 at 7:54 PM Mark Lentczner mark.lentcz...@gmail.com 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? — Mark ___ 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
On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell ndmitch...@gmail.com wrote: 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. Slightly OT: If you ever want to prevent cabal from trying to install a different version of a package (since you know it won't work, or will break things) you can put something like this in your cabal config: constraint: network installed I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network. Erik ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
On Mar 22, 2015, at 9:40 PM, Brandon Allbery allber...@gmail.com wrote: That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations. I do indeed think that this is interesting, because this thread is the first time I had ever heard of ghcformacosx. I've used Haskell on a Mac daily for several years now. I subscribe to (and read at least subject lines from) Haskell-cafe and Haskell mailing lists -- including Haskell Weekly News and HCAR -- though I'm only occasionally on reddit and very rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down my machine so much I preferred to reformat and roll back to 10.8, even though I was facing down a nasty deadline.) At the least, this end of the debate shows me that the community has some disagreement about what today's status quo is, an important fact to settle on before charting a course for the future. Richard___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
I can't speak for others but as a regular but enthusiastic Haskell user the platform always (not just since sandboxes) felt outdated and limited to the included packages since the rest of the Haskell ecosystem rapidly moved on after a platform release (or even during its stabilization freeze phase before a release). The platform is quite similar to Linux distributions like Debian stable or RedHat Enterprise Linux in that sense. Running software not in their repositories on one of those is a bit of a pain and not for the beginner too, just as running packages outside the HP can be when you start out with it. The majority of the Haskell power users (library authors, people interested in the language development itself,...) on the other hand run Haskell more like a rolling release Linux distribution, dealing with problems due to cutting edge versions as they arise which means cutting Hackage versions do not build on the HP. On the other hand new versions that do compile very rarely seem to cause major issues, offering little incentive to use older versions for power users outside enterprise support environments. Perhaps Haskell does need some kind of multi-tier system as those Linux distributions use? LTS and Stackage seem to be attempts to do just that. In any case, I do not think the HP is the best environment for the new Haskell user. Perhaps listing the possible types of users and their requirements and limitations would be helpful to decide what, if anything, should replace the HP. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
Okay, now I'm confused What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options? - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
Hi, What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options? I don't know what is the best. But here is what I know now: clang-xcode5-wrapper.hs (*1) works as a wrapper in many cases so far. We need to change the value of C compiler command in settings(*2). Unfortunately, in some commands, hsc2hs for instance, the command name gcc is hard coded. So, clang-xcode5-wrapper.hs should be installed as gcc. This gcc should have higher priority than /usr/bin/gcc in PATH. One concern is that users would get troubles with this new gcc. (*1) https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.hs (*2) /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
On Monday, October 14, 2013, Dag Odenhall wrote:
On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery
allber...@gmail.comjavascript:_e({}, 'cvml', 'allber...@gmail.com');
wrote:
Nope. Arch is a rolling release distribution whose policy is directly
opposed to the stable release philosophy of the Platform. They will
package latest versions of everything, not a stable release. You *cannot*
satisfy their requirements with the Platform; ignore them.
I would say it depends on what you mean by “latest”, since one answer
could be “latest haskell-platform”. Does Arch Linux ship the latest Python
packages, even if an older version is included in the stdlib of the latest
Python release?
There isn't a separate Python and Python Platform. Packages that ship
with Python are maintained in Python's repository. Those that are
also maintained separately usually have another package/module name
altogether so both can be installed without interfering with one another.
-bob
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months. -Edward On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner mark.lentcz...@gmail.comwrote: It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that. Back to this release: GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just this Autumn) - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it. SO, back to concrete ideas: *A) Minor release* *• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 *—or—* *B) Delay release* *• New packages:* running the normal process, just a month late *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5 *—or—* *C) Skip a release* *• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP *• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform *• Release in March: *aiming to sync with GNOME, assuming they're on to something! As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell. A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting. B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages. — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
It's worth noting that it's possible to have a working setup with Xcode 5,
it just requires having your own additional build of GCC locally (indeed,
that's my current setup), though this will likely have crazy linker errors
if I'm not careful :-) when linking a c++ lib built with clang.
On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear
of accidentally clicking on the XCode 5 upgrade button and winding up in an
unsupported configuration. That makes me very leery of option C, where
developers like me are treading on egg-shells around system updates for the
next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner
mark.lentcz...@gmail.comjavascript:_e({}, 'cvml',
'mark.lentcz...@gmail.com');
wrote:
It wasn't my intention to open up the whole question of scheduled
releases. HP has a regular release schedule, and there were many good
discussions leading up to it. As for the timing of those releases, last
time we looked into this there was no good release time that worked for all
the common Linux distro's release schedules. Perhaps GNOME has figured this
one out - they release stable end of September and end of March. We could
aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We
haven't even seen the first release yet! If it has stabilized by end of
February, then it could make it into the next HP (assuming we don't move
the schedule up to match GNOME). But I think realistically, one shouldn't
expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If
the community wants to see closer tracking, then we probably need to start
talking about a different way of producing GHC - with both stable and
experimental releases happening... when this idea has been raised in the
past, GHC central hasn't had the person-power to do it.]*
*
*
The next Mac OS X is indeed right around the corner (no official date
from Apple, just this Autumn) - the GM release candidate of both OS X
Mavericks and Xcode 5 are already in developers (and my) hands. My
understanding is that current HP just won't work on it - which means we
really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't
be adding anything, just roll it as normal now.
*• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC
7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—*
*B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is
needed to support Xcode 5
*—or—*
*C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get
7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant
increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to
something!
As attractive as some aspects of C are, it leaves anyone with a Mac out
in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise
mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us
an HP with some new packages.
— Mark
___
ghc-devs mailing list
ghc-devs@haskell.org javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
I guess my point is there's a number of work arounds that are easy for a
power user to support, but should NOT be the default setup or config
required for new users.
Eg: brew also provides an installer for apple-gcc42 and you could then
point your ghc settings file to.
That said, it's not a solution we probably want to encourage by default, it
definitely took me a while to cook up sane directions, and some of those
directions/approaches apparently become useless if you update to OS X 10.9.
(I think partly because the default C++ std libs on Mac shift, so you can't
easily build GCC on mavericks currently allegedly )
On Monday, October 14, 2013, Edward Kmett wrote:
As I do most of my development on a Mac I confess I currently live in fear
of accidentally clicking on the XCode 5 upgrade button and winding up in an
unsupported configuration. That makes me very leery of option C, where
developers like me are treading on egg-shells around system updates for the
next 6 months.
-Edward
On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner
mark.lentcz...@gmail.comjavascript:_e({}, 'cvml',
'mark.lentcz...@gmail.com');
wrote:
It wasn't my intention to open up the whole question of scheduled
releases. HP has a regular release schedule, and there were many good
discussions leading up to it. As for the timing of those releases, last
time we looked into this there was no good release time that worked for all
the common Linux distro's release schedules. Perhaps GNOME has figured this
one out - they release stable end of September and end of March. We could
aim to glide toward that.
Back to this release:
GHC 7.8 won't be ready for inclusion in an HP for quite some time. We
haven't even seen the first release yet! If it has stabilized by end of
February, then it could make it into the next HP (assuming we don't move
the schedule up to match GNOME). But I think realistically, one shouldn't
expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If
the community wants to see closer tracking, then we probably need to start
talking about a different way of producing GHC - with both stable and
experimental releases happening... when this idea has been raised in the
past, GHC central hasn't had the person-power to do it.]*
*
*
The next Mac OS X is indeed right around the corner (no official date
from Apple, just this Autumn) - the GM release candidate of both OS X
Mavericks and Xcode 5 are already in developers (and my) hands. My
understanding is that current HP just won't work on it - which means we
really should get something out to support it.
SO, back to concrete ideas:
*A) Minor release*
*• Minor rev:* since GHC and most packages haven't changed, and we won't
be adding anything, just roll it as normal now.
*• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC
7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5
*—or—*
*B) Delay release*
*• New packages:* running the normal process, just a month late
*• Bump for Mac: *get GHC central to put out 7.6.4 which has what is
needed to support Xcode 5
*—or—*
*C) Skip a release*
*• Go for 7.8:* push everyone (GHC central, library maintainers) to get
7.8 stable ASAP
*• Big Push for Packages:* use the time to push for a significant
increase in the packages in the Platform
*• Release in March: *aiming to sync with GNOME, assuming they're on to
something!
As attractive as some aspects of C are, it leaves anyone with a Mac out
in the cold for six months: They either can't upgrade, or can't Haskell.
A requires duplicate effort (mostly on my part), but is otherwise
mechanical... and not that exciting.
B deviates from our schedule, but if GHC can roll a 7.6.4, might get us
an HP with some new packages.
— Mark
___
ghc-devs mailing list
ghc-devs@haskell.org javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really not that big: 7.6.3 passes -x c when running the c compiler in preprocessor mode. Clang requires -x assembler-with-cpp to be compatible with the GHC codebase. So the workaround Austin Seipp helped me cook up is to simply wrap clang, detect it's being run in preprocessor mode (i.e. look for the args -E -undef -traditional), and make sure it gets passed -x assembler-with-cpp. You can see the entirety of it here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.hs I wrote the workaround as a a Haskell script, but someone with basic bash-fu could easily write it as a shell script. 7.6.3's settings file just has to be pointed at that wrapper instead of directly at clang and then everything works flawlessly with Xcode 5's clang, on 10.8 and 10.9 alike. Cheers Luke On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald carter.schonw...@gmail.com wrote: I guess my point is there's a number of work arounds that are easy for a power user to support, but should NOT be the default setup or config required for new users. Eg: brew also provides an installer for apple-gcc42 and you could then point your ghc settings file to. That said, it's not a solution we probably want to encourage by default, it definitely took me a while to cook up sane directions, and some of those directions/approaches apparently become useless if you update to OS X 10.9. (I think partly because the default C++ std libs on Mac shift, so you can't easily build GCC on mavericks currently allegedly ) On Monday, October 14, 2013, Edward Kmett wrote: As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months. -Edward On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that. Back to this release: GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just this Autumn) - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it. SO, back to concrete ideas: *A) Minor release* *• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 *—or—* *B) Delay release* *• New packages:* running the normal process, just a month late *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5 *—or—* *C) Skip a release* *• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP *• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform *• Release in March: *aiming to sync with GNOME, assuming they're on to something! As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell. A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting. B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages. — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org
Re: Wither Haskell Platform 2013.4.0.0
with all due respect, we can't delay a HP release this fall, we need one that works with OS 10.9 Mavericks / Xcode 5 this fall. as Austin has opined, the right way to do this is to have a bug fix release for 7.6 this fall that addresses the OS X issues. -- Carter Schonwald On October 13, 2013 at 4:22:34 PM, David Luposchainsky (dluposchain...@googlemail.com) wrote: I think making the HP release cycle purely time-based is not the best option. For a large amount of users, the HP and what comes with it (including the associated compiler) is what Haskell is. If something does not work with the HP, then Haskell does not work. - Support for the latest OS is crucial, probably most importantly to avoid bad publicity. Hard to install is an image that's not easily changed when search engines are full of hacks that make it somehow work again. - Are there significant changes in the HP libraries compared to the last release? Is there a good reason to make people update to the latest packages? - In the light of the AMP, I think a relatively early adoption of 7.8 would be very beneficial in order to prepare Hackage. Releasing this year with 7.8 would not be a good idea, but maybe next spring (which would be halfway between the usual HP release dates) is possible? In short, my vote is delay until it works with all OS and 7.8. David ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that. Back to this release: GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just this Autumn) - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it. SO, back to concrete ideas: *A) Minor release* *• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 *—or—* *B) Delay release* *• New packages:* running the normal process, just a month late *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5 *—or—* *C) Skip a release* *• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP *• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform *• Release in March: *aiming to sync with GNOME, assuming they're on to something! As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell. A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting. B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages. — Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
