- Libraries - Haskell.org

TLS Support
by Dominic Steinitz 25 Mar '15

25 Mar '15

I don’t often venture an opinion here but I would be very much *against* using OpenSSL given the number of vulnerabilities it continues to experience. There’s http://www.mitls.org/wsgi/home which has been formally verified and our own https://hackage.haskell.org/package/tls. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com On 25 Mar 2015, at 09:08, libraries-request(a)haskell.org wrote: > 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.

1 0

Re: Cabal and simultaneous installations of the same package
by Michael Snoyman 25 Mar '15

25 Mar '15

I replied on the GSoC proposal itself, but since it was cross-posted to the mailing list, I'll include my comments here too: I've reviewed this proposal, and I think it outlines a step in a good direction. As I've discussed with Duncan in the past, my biggest concern around a system like this is the complexity of the UI for a developer; having to juggle different environments just to get basic work done could be a significant hurdle. As long as attention is paid to ensuring no "UI regression" for simple cases, I think this is worth pursuing. On Tue, Mar 24, 2015 at 7:17 PM Vishal Agrawal 1<vishal4556(a)gmail.com> wrote: > I am already planning to do a GSoC project based on it with a slightly > larger aim. You can find my work in progress proposal at > https://gist.github.com/fugyk/37510958b52589737274. Also I have written a > patch to make cabal non-destructive at > https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732…. > Can you review the proposal and give me suggestions. >

1 0

Fixing Fix
by David Feuer 24 Mar '15

24 Mar '15

There are a good number of different packages that define either newtype Fix f = Fix (f (Fix f)) or something equivalent except for naming. Most of the name variation is in the name of the data constructor and/or record selector. This does not look like an ideal situation to me. Most problematically, the only way to convert one to another is with unsafeCoerce. I think it would be rather nice to choose one canonical place for this definition, and let everyone else use it. Ideally, it would be nice to use some GHC pattern magic and such to paper over the differences between the data constructor names, but I don't know if that's possible or not. David Feuer

6 15

Re: Cabal and simultaneous installations of the same package
by Vishal Agrawal 24 Mar '15

24 Mar '15

I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732…. Can you review the proposal and give me suggestions.

1 0

Type roles for UArray?
by wren romano 24 Mar '15

24 Mar '15

So I was working on porting my libraries to work for GHC 7.10 and I ran into a snag. Unlike the concrete type Data.Array.Array, the concrete type Data.Array.Unboxed.UArray is defined as being nominal in the second type argument— is this a bug? If not, then why must it be nominal? Shouldn't (UArray a New) and (UArray a Old) have the same representation in memory? Using unsafeCoerce has always been safe here in the past... -- Live well, ~wren

5 6

Re: [haskell-infrastructure] wither the Platform
by Miëtek Bak 23 Mar '15

23 Mar '15

On 2015-03-23, at 18:13, Andrew Farmer <afarmer(a)ittc.ku.edu> wrote: > I personally just download the latest bindist from the GHC site and > bootstrap cabal myself. Partly this is because my work requires me to > have the latest GHC, so maybe I'm not in the HP's target demographic. > That said, I would love if there was a platform that just did that (+ > whatever is needed to get that to work). Maybe at the end of the > minimal install, give me a choice between stackage and hackage and set > the remote-repo in my cabal file appropriately. I’m happy to say `halcyon install --cabal-remote-repo=…` does just that. See the Halcyon tutorial and reference for details: https://halcyon.sh/tutorial/#install-ghc-and-cabal https://halcyon.sh/reference/#halcyon_cabal_remote_repo -- Miëtek https://mietek.io

1 0

Re: [haskell-infrastructure] wither the Platform
by Gershom B 23 Mar '15

23 Mar '15

On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley <acowley(a)gmail.com> wrote: > > I don't understand this attitude. You say that neither new users nor package > authors agree with your stance on the HP, so you want to force their hands. > Presumably package authors know what they're doing for themselves, and the > majority of evidence we have is that new users who stick with the language > do not like the way the HP works > <https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/>. No, this is not what I said. I was explaining that it rather difficult, even if we wanted to force their hands, to imagine that we could do so. I will say that I do not share your belief that package authors know what they are doing, in general. If they did, I would imagine that nearly all packages would ensure they would work with the current platform. But getting programmers to all agree on something like that is herding cats, and all it takes is a few people saying "feh on the platform" but nonetheless producing otherwise good packages that come into widespread use to _in general_ mean that many packages which directly or indirectly want to use those dependencies must also now split off from support for the platform. So I agree that people have voted with their feet, and we need to catch up to that. In fact, it seems to me from this discussion that there are only _two_ things we need to do to make the platform the recommended install path for all platforms again: 1) Incorporate the improvements to windows builds that have been pioneered by the MinGHC project (in particular so that platform-installed windows ghc can build the network package properly, and perhaps even the GL stuff). 2) Address the problem that in a sandbox you will get a different install plan depending on your global package db. I would suggest this be done by setting a default preference of the sandbox to ignore global packages, and allow that to be overridden with an easily configurable flag or setting or the like. That way, new users can pay the longer compile price for a guaranteed-safer experience, and more experienced users can choose to use / build up a broader library of packages they can share across sandboxes. (Certainly some "nix-like tricks" in cabal could also help address the repeated builds problem, but a flag can be implemented much more quickly as a short-term measure). All that said, I think it would _still_ be better if more package authors paid attention to backwards-compatibility across releases, and it would _still_ be better for new users if they didn't go off and bash their heads against the newest and least stable packages around. But that is indeed a different problem. Cheers, Gershom

1 0

Re: [haskell-infrastructure] wither the Platform
by Gershom B 22 Mar '15

22 Mar '15

Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines. A) Users that sandbox and users that do not. B) Libraries that maintain HP compatibility and libraries that do not. The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes — platform-installed packages being available in sandboxes and causing trouble. However, the current solution we push to new users is lacking in certain ways. In particular, I really don’t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc. Furthermore, it is _very_ important to have some community process to “bless” or suggest some set of packages from the zoo of hackage as the “typical” way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc. Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes. Overall I tend to agree with dons’ comments on the reddit thread (http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) and think the key idea is to preserve _both_ the “one stop installer” aspect of the platform and the “blessed package set” element, but to decouple them from one another. This leads to the following proposals: 1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place. 2) For generic linux point to both ghc and cabal binaries from the core teams. 3) Continue to pick out and list a compatible, “blessed” set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains. 4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes. And of these I have one outstanding question — while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can’t solve that, then the MinGHC approach doesn’t yet provide a strictly better solution. Cheers, Gershom On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale(a)sefer.org) wrote: > 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 > _______________________________________________ > haskell-infrastructure mailing list > haskell-infrastructure(a)community.galois.com > http://community.galois.com/mailman/listinfo/haskell-infrastructure >

2 1

Re: wither the Platform
by Mark Lentczner 21 Mar '15

21 Mar '15

Eeek! I really really did mean to make the subject *whither*, not *wither!*

2 1

Proposal: parametrize tree stem container type in containers
by M Farkas-Dyck 19 Mar '15

19 Mar '15

A few years ago I uploaded the package generic-tree to Hackage (before I knew the customary version scheme, sorry about that) which has trees parametrized over stem container type: data Tree v a = Node a (v (Tree v a)) As this is a functional superset of the containers tree, I think it appropriate to include in containers, which I hereby propose. Ultimately, if this is accepted, I would like to define the list-specialized tree in terms of this.

2 1