November 2015 - Haskell-community

Request for comment: New haskell.org download page
by John Wiegley 12 Jul '16

12 Jul '16

As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold: a) add stack as an explicit option, and b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice. We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point. At the following link, you'll find a draft version of the new page for comment: https://gist.github.com/jwiegley/153d968ddfc9046ee4c9 Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision. However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us. Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path. At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too. Thank you, John Wiegley

21 50

Downloads page & Haskell for Mac
by Manuel M T Chakravarty 19 Nov '15

19 Nov '15

Sorry for jumping late into the discussion surrounding the downloads page. However, I would like to request that Haskell for Mac <http://haskellformac.com> be added to the page. I’m of course happy to make the edits myself and to submit a pull request, but I’d first like to ask what the community thinks is an appropriate way to add this Haskell distribution. Would it be appropriate to just add a fourth bullet point to the current list of three (Minimal, Stack & HP)? Cheers, Manuel

4 10

Expanding the Core Libraries Committee
by Edward Kmett 13 Nov '15

13 Nov '15

At present the core libraries committee consists of 7 members: 6 regular members and one ex-officio appointment for the Haskell Platform maintainer. https://wiki.haskell.org/Core_Libraries_Committee The size of this committee was originally selected to be in line with the size of the extant haskell.org committee. During a meeting of the committee last week, we decided it is a bit too small to fulfill the function of adequately representing the broader community while still providing a sufficient institutional memory. Consequently, we've resolved to replace the current Haskell Platform maintainer appointment with 3 additional seats on the committee. This will grow the committee to 9 members. Pleased be advised, membership on the committee is a commitment to a fairly active role. For more information on some the processes surrounding the core libraries, please see the library submissions page on the Haskell wiki: https://wiki.haskell.org/Library_submissions If you are interested in self-nominating for the core libraries committee, please send an email to core-libraries-committee(a)haskell.org. Thank you for your time and consideration. -Edward Kmett Core Libraries Committee Chair

1 0

Fwd: Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0