- Haskell-community - Haskell.org

Call for Haskell.org committee self-nominations
by John Wiegley 18 Feb '16

18 Feb '16

Dear Haskellers, It is time to put out the call for new volunteers to the haskell.org committee. We have one member due for retirement since this past October: Gershom Bazerman. The committee would like to thank him for his excellent service. To nominate yourself, please send an email to committee at haskell.org by March 4, 2016. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org, or contact one of us individually. Thank you, -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

1 0

Haskell.org Committee Financial Statement 2015
by Gershom B 17 Feb '16

17 Feb '16

Dear Haskellers, The Haskell.org Committee [1] manages funds for haskell.org and oversees haskell.org infrastructure. The funds available to Haskell.org generally come from two sources: 1) Mentor payments from the Google Summer of Code program. 2) Since the end of 2013, occasional donations [2] from the Haskell community at large. Our funds are held by Software in the Public Interest, a 501(c)3 US non-profit, through which we also accept donations. In return for its services, SPI receives 5% of donations to Haskell.org. According to our charter, "Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year." Included in this message is a brief statement of Haskell.org assets over the period 31 December 2014 - 31 December 2015. Note that our expenses are nearly entirely hosting, with a small overhead incurred by SPI and payment processing. The bulk of our income this year, over which we did minimal fundraising, is $7,000 in mentor payments from google summer of code 2014 (mentor payments for 2015 have not yet been received). Hosting fees are down from years past, as we have migrated more of our infrastructure away from Hetzner and to Rackspace, which donates to us free hosting. 1. Income and Expenses Total income over 2014: 7751.46 Total expenses over 2014: 892.03 ---- Net income over 2014: 6859.43 3. Total Balance Balance as of 31 December 2014: 26,422.91 Balance as of 31 December 2015: 33,547.34 Note: As of December 2015, we have a moved a large chunk of our balance out of the SPI-held account and to a new account set up directly under the control of Haskell.Org, as Haskell.Org is now registered as a nonprofit 501(c)(3). [1] https://wiki.haskell.org/Haskell.org_committee [2] https://wiki.haskell.org/Donate_to_Haskell.org Best, Gershom Bazerman for the Haskell.org Committee

1 1

(no subject)
by Gershom B 21 Dec '15

21 Dec '15

Dear all, The Haskell.org committee held a board meeting on 10 November, where we approved a formal set of bylaws and conflict of interest policy. The resolution passed is available online at: https://wiki.haskell.org/wikiupload/9/9c/Haskell-org-board-res.pdf The purpose of this was to formalize our structure so as to operate properly as an incorporated nonprofit entity whose business is conducted in accordance with 501(c)(3) of the 1986 IRS code. We received a letter from the IRS on 10 December indicating that our exempt status has been approved. We have been, and remain, an associated project of Software in the Public Interest, a nonprofit association, which has held our assets for us. The desire to incorporate on our own was so as to be able to bring our resources under more direct control. We hope that this is an initial step in being able to be more active and responsive with regards to haskell.org resources. As a first step, a transfer of some of our funds held by the SPI has now been made to a direct haskell.org account. I intend to update the committee page on the wiki to reflect the changes to our structure: https://wiki.haskell.org/Haskell.org_committee Warm Regards, Gershom Bazerman, for the Haskell.org committee

2 1

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

How to make the community more welcoming?
by Jason Dagit 08 Oct '15

08 Oct '15

I stumbled on this article today: http://sarah.thesharps.us/2015/10/06/what-makes-a-good-community/ I think the author brings up some good points. I tried to share this on /r/haskell, perhaps unsuccessfully: https://www.reddit.com/r/haskell/comments/3nw9dh/what_makes_a_good_communit… I'm hoping that this list is a better place to discuss the points made in that article. Below are my thoughts (mostly copied from reddit). My point with bringing this up is to help us improve our community. It's not meant to unfairly criticize the actions of any particular person or anything like that. I like Haskell and I want our community to be the best that it can be. Are there specific things within reach that we could adopt from the examples in the article? I think we largely have level 0 and 1 down. It looks like level 2 where we start to loose our footing. Level 2: meaningful contributions The next step is figuring out what to do with these eager new diverse > candidates. If they’ve made it this far through the gauntlet of toxic tech > culture, they’re likely to be persistent, smart, and seeking a challenge. > If you don’t have meaningful bigger projects for them to contribute to, > they’ll move onto the next shiny thing. > Signs of a level 2 welcoming community: > * Newbie todo lists > * Larger, self-contained projects > * Welcoming, available mentors > * Programs to pay newbies (internships, summer of code, etc) > * Contributors are thanked with heartfelt sincerity and an explicit > acknowledgment of what was good and what could be improved > * Community creates a casual feedback channel for generating ideas with > newcomers (irc, mailing list, slack, whatever works) > * Code of conduct encourages developers to assume good intent We use the google summer of code as a way to pay/mentor new contributors, but I think we need more mentors and more newbie friendly projects. Just need to make it happen, I guess. Also, it looks like we incorporate some of the Level 3 things too, with committee rotations. Thanks for your time, Jason

1 0

Request for comment: New haskell.org download page
by 韩冬 25 Sep '15

25 Sep '15

As a newcomer(start learning about 3 months ago), I also will stand up and say i use the HP, i did meet some problems at the beginning, but the problems are all solved by reading documents and understanding more about ghc package management. Now i’m playing well with cabal sandbox and never had any problems. The main reason to use HP is that HP make ghci usable(i mean fire ghci anywhere, not cabal repl inside a project), otherwise i have to install lots of global packages by my self. Cabal and cabal-install do need some document care, but that’s all, global package doesn’t harm as long as you use sandbox. Finally, i’d say i really wish the minimal installer comes first with document link, that’s the right way to let newcomer understand how the ghc package management works and how to choose between stack/cabal.

1 0

Request for comment: New haskell.org download page
by MightyByte 24 Sep '15

24 Sep '15

On Thu, Sep 24, 2015 at 8:23 PM, John Wiegley <johnw at newartisans.com> wrote: > > Perhaps we need a poll. So far the presented options are: > > 1. HP Stack Minimal > 2. Stack HP Minimal > 3. Stack Minimal HP > 4. Minimal HP Stack > 5. Minimal Stack HP I vote for #4.

1 0

Haskell Platform as the default recommendation considered harmful
by Christopher Allen 21 Sep '15

21 Sep '15

Here are some quotes from end-users regarding Platform. This is just what I found on the web and from skimming IRC logs, it doesn't include many hundreds more of examples from IRC of new people _in particular_ getting stuck because they didn't understand they were conflicting with globally installed packages. New people do not understand: 1. ghc-pkg 2. The global vs. user package databases 3. Cabal 4. What Platform does to their build environment New Haskell users are least equipped to understand errors caused by: 1. Package version conflicts 2. Something innate to their install, rather than something wrong with their package constraints. Part of the problem is that the people making decisions on these matters are not the people on the frontlines helping new people in IRC or otherwise in the wild with sufficient regularity to see how often this catches people up. It's less common than it used to be, but that's due in large part to people following the install instructions on https://github.com/bitemyapp/learnhaskell and using things like MinGHC and Stack. Comments like this from the committee: "Despite the controversies over if platform is "right for beginners" it needs to be provided from the downloads page generally." Are representative of the experience the community has had trying to get the situation rectified and people routed to alternatives so that unnecessary friction isn't encountered. Past comments I've made on this: Haskell libraries typically move pretty quickly...Having cabal sandbox init && cabal install $package just work is important and Platform compromises that as the globally installed packages becoming out of date between releases. Doug Beardsley, one of the core Snap developers said this in reply: "This. This is the biggest reason I don't use the platform and have advised a number of relative newcomers to switch from the platform to straight GHC when they encountered build dependency problems." I used to tell people in my guide to install Haskell Platform, but I stopped because it kept creating problems. Haskell Platform causes trouble for new people when the globally installed packages get old. These very same new people are the ones least equipped to cope with or understand the problem or where it comes from. Platform should be recommended when it is the best option available for the majority of Haskell users. Quotes from end-users: "The HP downloads have been moved "above the fold" with a clear demarcating line separating the "first class citizen" (HP) from the other, minimal installers. Frankly, I was astonished when I went on the other day and saw this change, since originally there was pushback about even having HP on the downloads page at all!" (re: content changes on the new haskell.org website) "I know I'm a beginner, but I don't even understand what problem #Haskell platform is trying to solve." "Yeah, I was bitten by Haskell Platform a few weeks ago. I'll have to check out Stack though." "I haven't used haskell for a few years, installed haskell platform the other day, it works fine but I can't cabal install" (said 2015-09-15 btw) > As per #55 we want less biased presentation of bare install vs. platform, not more. "Ok. (I recommend people to Haskell sometimes, and I see HP hurts them a lot, as they all want to do webdev) Especially now that Stack is out and picking up momentum, I personally consider HP completely superseded." "Windows user here. I dumped Platform the day MinGHC happened, and have never looked back." "On OS X, in my experience it is way easier to set up Haskell without HP than with, fwiw. I don't think it was always this way, but it has been for at least a year." "Actually, I don't understand why we need Haskell Platform at all? Now, when stack exists, Haskell Platform is useless, I think. "Haskell with batteries included"? Yes, but what batteries are? Compiler+Interpreter, Cabal 35 "core" packages. With stack I can setup ghc-infrastructure and install any packages I need." "It seems to me that within the community, we all know stack is the clear winner, and we can recommend it to whomever is showing us an interest in Haskell. Unfortunately, haskell.org appears to be the landing portal for the language to a newcomer with no existing ties to the community, and thus no one to recommend stack over it. Stack is so obviously a better tool for a new user, it's unbelievable. /subjective opinion" "Yes, a regular frustration when helping folks on IRC is that the first three steps have so often been to, 1. Apologize 2. Instruct how to uninstall what they have 3. Start again with GHC and cabal The effort made at packaging GHC on both Windows and OS X are really solid pieces of work. It looks like Stackage LTS will provide a nice basis for a set of libraries moving forward." "as a newborn Haskeller, I agree. Platform (OSX) was a huge pain, uninstalled it, learned cabal sandboxes, sometimes nuke them, everything works." "I find the platform to be a huge burden to beginners on OS X. It just leads to cabal hell. Anything except the minimum to build cabal-install in the global sandbox == super bad." "The platform was very confusing to me as a beginner, and only now that I know what I'm doing do I see what it was trying to accomplish. I'm depending on the awesome PPA, hopefully GHC can be made easier to get running without such a thing on other platforms." "Actually there is a disadvantage with the HP, as I pointed out already in an email-response, as the extra HP packages get registered into the global package db, and therefore pollute the sandbox environment with those extra packages." "The problem is that Cabal prefers the version already installed (i.e. exposed via the global pkg db), when I want the Cabal solver to be as unrestricted as possible in a sandbox in order to get the latest available versions rather than those imposed by the HP." "So is there really a simple way (as you seem to suggest) to hide all the extra HP-provided package versions inside a sandbox?" Recommended solution: > add an entry like this to the constraints field in the cabal.config file in that sandbox: > constraints: attoparsec source "Funny because I have been using the Haskell ecosystem since roughly one or two GHC versions longer than the platform has been around and to me it always felt outdated on average over the lifetime of one HP release. GHC 6.12.1 was released in December 2009, the next platform Beta release was in March 2010 and the next actual release in July 2010. So the platform contained the outdated GHC 6.10 for the better part of a year after the new GHC version was released. GHC 7.0.1 was released in November 2010, again we had to wait until March for a matching platform release. GHC 7.2.1 was release in August 2011 but was marked as a technology preview and completely ignored by the platform. GHC 7.4.1 was released in February 2012, the platform release including it was in June, coinciding almost exactly with the GHC 7.4.2 release which was then ignored by the platform until November, after even GHC 7.6.1 had been released in September 2012 already. To get GHC 7.6 in a platform release we had to wait until May 2013 when the reasonably current (release in April 2013) GHC 7.6.3 was included in the only platform release of that year. In April 2014 we got GHC 7.8.1 and in August 2014 we got a platform release for it which included 7.8.3, the current GHC release at the time and until GHC 7.8.4 was released in December. Not to mention that the HP is not even handled like a regular stable distribution, e.g. it doesn't even update patch levels of packages or compilers." "Haskell does still have major "ease of installation" problems in my experience." "using Haskell Platform at all might cause troubles; it's explicitly recommended against [...] because it uses the global package database." "Haskell Platform feels a bit like Prelude; fine for people who are just using it for small self-teaching projects, but once you're supposed to do something "serious" then people seem to throw up their hands and say "No! never mind that.". I don't know. Maybe I've got the wrong impression. Now that I know enough cabal to get by and not screw myself over (by creating dependency hell), I feel like Haskell Platform might not be relevant to my needs any more." "No, you're perfectly right. And while HP may be up to date right now, it'll be out of date next month and it will keep getting more and more obsolete until the next release in a year or so." "It's still bad and cabal is still bad. I was in #haskell on IRC not too long ago and they couldn't even figure out why a haskell-platform install couldn't upgrade its own cabal with no other packages installed." (Example of Cabal getting blamed for problems with Platform) "If you're on OS X or Linux, you should not use the Haskell Platform. It's a whole lot of pain for literally no gain..." "The Haskell Platform was an attempt to define one but many don't like to depend on it." "I suggest you to use hvr's GHC packages. That way you can simply apt-get install ghc-7.10.1 cabal-install-1.22" "What is the best way of installing GHC on OS X? There's Haskell Platform, Homebrew GHC/Cabal formulas, andHaskell for OS X. I've been told that Homebrew formulas were broken a few months ago, and that Haskell Platform is not good if you plan on doing anything but the most basic things." Example links: https://www.reddit.com/r/haskell/comments/390msw/unable_to_install_ghc_and_… https://www.reddit.com/r/haskell/comments/390msw/unable_to_install_ghc_and_… https://www.reddit.com/r/haskell/comments/390msw/unable_to_install_ghc_and_… https://github.com/haskell/haskell-platform/issues/165 https://www.reddit.com/r/haskell/comments/3b1yuk/haskellinfrastructure_fwd_… https://www.reddit.com/r/haskell/comments/3b1yuk/haskellinfrastructure_fwd_… https://www.reddit.com/r/haskell/comments/3b1yuk/haskellinfrastructure_fwd_… https://www.reddit.com/r/haskell/comments/3b1yuk/haskellinfrastructure_fwd_… https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpm8okr https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmk4vt https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmclvo https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpm8l4a https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmbopv https://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmljeh https://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform… https://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform… https://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform… https://www.reddit.com/r/haskell/comments/2vy1lw/new_haskell_homepage_is_li… https://www.reddit.com/r/haskell/comments/2vy1lw/new_haskell_homepage_is_li… https://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform… https://www.reddit.com/r/haskell/comments/38br54/help_wanted_for_haskell_pl… https://www.reddit.com/r/haskell/comments/38br54/help_wanted_for_haskell_pl… https://news.ycombinator.com/item?id=8083705 https://news.ycombinator.com/item?id=6300091 https://news.ycombinator.com/item?id=9808260 http://www.davesquared.net/2014/05/platformless-haskell.html http://stackoverflow.com/questions/32532120/what-is-the-haskell-standard-li… http://stackoverflow.com/questions/32126861/bytestring-types-fail-when-inst… https://www.reddit.com/r/haskell/comments/3fqiff/dont_give_up_on_haskell/ct… https://github.com/haskell-infra/hl/issues/93#issuecomment-75862519 https://github.com/haskell-infra/hl/issues/55 http://ircbrowse.net/browse/haskell?id=21305217&timestamp=1440372668#t14403… https://twitter.com/mac10688/status/644600976897347584 https://twitter.com/JulianBirch/status/640525865793810432 https://twitter.com/dshevchenko_biz/status/640416836694245376 https://github.com/haskell-infra/hl/pull/130 Seem like a long list? Welcome to the bloodbath. I urge you try to find a similar level of discontent in other programming language communities with their community infrastructure like this. My preference? Stop linking people to Platform until, at minimum, the globally installed packages are removed per: https://github.com/haskell/haskell-platform/issues/206#issuecomment-1383344… -- Chris Allen Currently working on http://haskellbook.com

5 10