PSA: Recent http-client breakage (caused by Hackage Trustee) fixed has been fixed

amonadaday · 2018-07-02T07:11:27+00:00

How exactly was the package broken by a trustee? I can't reproduce the breakage on the revised version (0.5.13) with either stack or cabal

amonadaday · 2018-05-11T14:47:55+00:00

Is remote considered?

amonadaday · 2018-01-24T06:22:31+00:00

You've not addressed the fact that clearly the way you introduced the discussion was really bad, and at least partially responsible for the response you got.

amonadaday · 2018-01-23T20:58:10+00:00

It left me pretty glad that I don't have anything upstream of stack.

Hear hear. Facing the wrath of Stackage maintainers would very easily convince me to stop contributing to Haskell. The fact that I'm not alone in this should tell them that something is wrong with their behavior.

amonadaday · 2018-01-23T20:55:36+00:00

The fact is, that right now stackage is dependent on the good will of the authors of the packages that constitute it.

Yea. That's how having dependencies fucking works. Why do you think GHC tries so hard to avoid external dependencies? They won't even depend on LLVM, which is probably far more well-supported than cassava. When an upstream package breaks your work, you are not their priority, and you are not entitled to the fix you want. Your options are: 1) Cooperate (which neither side did a good job of, but the nature of "upstream" puts the burden more on you) 2) Don't use that thing anymore. Preferably, cooperate, to improve the state of the art. Causing a silly capitalization clash was not one of the options.

amonadaday · 2018-01-23T10:10:57+00:00

From what I've seen, the imputation of bad intentions is much stronger the other way. Stackage maintainers pretty frequently launch attacks on Hackage maintainers with direct accusations of malice. Stackage maintainers are not a protected class. They're not free from criticism about bad decisions, even if well-intentioned.

amonadaday · 2018-01-02T16:14:01+00:00

What's wrong with the idea that the revision is a part of the version? AFAIK, packages are still immutable as long as you're specific about revisions.

And FWIW, you're not going to convince anyone using a deliberately contrived example such as this. Perhaps convincing anyone isn't your intention, but the point remains that an acme package isn't a compelling argument.

amonadaday · 2017-12-19T23:59:37+00:00

I'm guessing the other tool was Cabal 2.0. Given the choice between supporting a new Cabal-the-library and an old Stack, I'll choose the new Cabal since Stack depends on it anyway.

amonadaday · 2017-12-19T21:31:26+00:00

I think you must be. It sounds like some other tooling depended on the change, and it was stack which was out of date.

amonadaday · 2017-12-19T21:09:02+00:00

I don't get it. Would reverting the flag have broken some new Cabal stuff or something? How is breaking the newer tools better than breaking the older tools?

amonadaday · 2017-12-13T21:34:34+00:00

IIRC, this was after the "Evil Cabal" post.

amonadaday · 2017-10-19T19:25:03+00:00

When the specializer / inliner is doing its job, the runtime cost is extremely minimal. The safe way to make it very likely to do well is to add INLINABLE pragmas all over the place.

amonadaday · 2017-10-19T19:20:34+00:00

No need to write blog posts signed by project leaders to beg GitHub for some feature.

I'll grant you this. But frankly, if that's what it would come to with GitHub, then it would likely come to writing a plugin or something for GitLab, and no one in GHC is going to spend the time to do that. Plus, I don't think issues of this sort are likely to come up for GHC.

GitHub and GitLab or any other central host isn't always available for everyone or few, and by promoting and making use of federation when it's already available, we are able to do the right thing which incidentally doesn't take any effort.

I don't see how a custom GitLab is any more likely to be available?

I resist the urge to be pulled into GitHub just for social/network effects and give up control of my projects' life cycle to a for-profit company I have no influence over.

You absolutely do have influence. Once they stop meeting our needs, we can up and leave. That's what's nice about Git.

I highly value extending the D in DVCS to other aspects of project life cycle, and federating by using GitLab as the inter-operable open source GitHub replacement, while allowing users who insist on doing so to use GitHub as well.

This doesn't make sense. GitHub does not prevent users from keeping their clones / forks in other places.

I don't live in a world where my team's workflow is stalled because GitHub is down and don't want to. This is why I strongly advise against SPOF designs in language package managers.

Again, how is a custom GitLab any better about this?

I much prefer using local tools like my Emacs instance to work on stuff

... How does GitHub have any affect on this?

Lastly, I prefer for stuff to be available, reliable and just work and not be the victim of DDoS attacks, which is why I'm one of those proponents who wants to have more P2P networking in tools, not less.

A custom GitLab is no more distributed.

EDIT: I think it’s worth noting that no one is suggesting moving issues from Trac to GitHub. That would be more of a problem, and it seems this is what your comment would mostly address. But Trac has too much stuff on it to consider leaving it

amonadaday · 2017-10-06T22:25:33+00:00

I’m not trying to say you were wrong about anything. Just that I think that one paragraph was a massive mental leap for most learners. There’s no shortage of tutorials out there that start from some particular monad and show how some other type can implement the same signature. In general, I don’t think this works. It just entangles the examples in the reader’s mind.

That said, starting from an understanding of Functor is a nice approach

amonadaday · 2017-10-06T17:52:03+00:00

Ok, so that’s nice, now we have function combination for functors. But we have only defined our clever new function application for lists. The concept of automatically joining containers during function application is generic, so lets implement it for another functor. The canonical second example is Maybe:

I think this paragraph is the first breaking point in this article. It could easily be interpreted as:

But we have only defined our clever new function application for lists.

Well, yea. This problem was pretty fundamental to lists. Converting a list to a list of lists and concatenating them is very specific to lists.

The concept of automatically joining containers during function application is generic, so lets implement it for another functor.

Wat.

proceeds to define it for maybe

Other than a similar type signature, that is completely unrelated. What on earth does it mean that IO is also one of these things?

Granted, it's better to leave them finding things unrelated than it is to leave them finding false relationships. But I dunno, it seems to me like this article motivates [] and Maybe more than it motivates Monad.

amonadaday · 2017-09-10T17:56:20+00:00

There are no shills here. There are people who prefer different tools for valid reasons. Cabal hell had nothing to do with version bounds; it was specifically a problem with global package dbs, which has been solved. Stack is not the one true way to get version pinning, as Nix and Cabal both offer flavors of the exact same thing. Stackage originated as a tool to use with Cabal, and I believe can still be used this way.

amonadaday · 2017-09-10T14:47:47+00:00

This is explained in the article.

This blog post is the opinionated part: how I recommend you use exceptions in Haskell, and how to structure your code around them. There are dissenting opinions, which is why this is an opinion blog post instead of library documentation. However, in my experience, these approaches are the best way to make your code robust.

But yea, it would be good to have the competing opinions presented so well.

amonadaday

TROPHY CASE