babygirl
Couldn't match expected type `[t0]' with actual type `IO String'
In the return type of a call of `readFile'
In a stmt of a 'do' block: f <- readFile inFile
In the expression:
You must log in to comment.
in reply to @GloopQueen's post:
"babygirl the kamehameha is a powerful technique that gathers a large amount of energy into a single point to be directed outward as a beam"
in reply to @tati's post:
in reply to @ShugoWah's post:
in reply to @fullmoon's post:
we are building GHC anyway, right
one more patch won’t hurt, right
my recollection is that the patch count was up to four or so on top of 9.4.2 on Nix at work. thank fuck for Nix but lmao. i know at least one is upstream by now.
That’s why I have a hard “2 versions behind upstream” policy, which means we are gonna update to 9.2 when it hits nixpkgs in a few days :P
given that only one of the patches was to address a critical aarch64 code generation bug which also existed in 9.2 but wasn't exposed, idk. rest are like, perf or other stuff. 9.4 cut compile times by an entire third to half.
also, ghc fucks up in patch releases. for example 9.2.5 and 9.4.3 can do math on arm64 correctly but a severe optimizer bug introduced in that patch release breaks the ListLike test suite.
i don't think the answer to "compiler is broken yo" is more waterfall. we were on 9.2 seven months ago. rustc releases every 6 weeks and people don't bake it for a year so IMO ghc is doing something very wrong to have broken trust so badly. perhaps the fact that hydra has found two critical regressions by just running hackage test suites that should have blocked it getting out the door at all has something to do with it.
Okay fair, but saying “9.4 has bugs that 9.2 also has” is not a good argument, at least we generally know most bad bugs an old compiler release had, as opposed to the unknown unknowns of a new one.
That GHC doesn’t run all its own test suites before releasing is a very silly way of introducing bugs, I agree. OTOH doing anything to the compiler is already super unforgiving esp concerning various benchmarks, so I don’t know if making that harder is a good approach.
(staying on a stackage LTS has other great advantages btw, such as the nixpkgs hydra caching most things, great interoperability of packages, mostly stable versions of most packages etc.)
There's a specific reason they did it at work: compilation is 30-60% faster due to patches they funded. And I would much rather be on an upstream release even if it's a new one.
The 9.2.5 ListLike test suite breakage was due to broken backports. It wasn't present in 9.2.4. I really think that GHC should, given their slow release schedule, run nixpkgs haskell CI against release candidates.
compilation is 30-60% faster due to patches they funded.
Well … I guess if I ever have to patch GHC to be fast enough for my use-case I will also have the monetary resources to stay on master lol
btw I’d also never run into an aarch64 bug, simply because macos is not a stable nor well-supported platform so I stay away from it. At least until the whole ARM thing has settled down a bit for desktops/servers.
it's not so much "fast enough for a use case" as "developers go way faster when their compiler is faster". i would not want to be the one dealing with api breaks of master on like hls and so on, so i feel like it's fairly reasonable to be on a very new release version.