-
Notifications
You must be signed in to change notification settings - Fork 175
GHC 8.2.1 support #900
Comments
I don't have any plans to work on it myself in the near future and I don't know of anyone who is but patches are welcome and I'd be happy to help on IRC. |
PR: #911 |
(I wonder when ghc-mod is available for GHC-8.2.1)???? |
This is blocking on cabal-helper support for Cabal-2.0 currently. Most of the boring busy work on that front is already done, the CI is green for all currently supported Cabal versions and we have a straight forward test case which fails with Cabal-2 but works with older versions. Basically Firstly we need to support internal libraries which the code currently just ignores and secondly we need to figure out what to do when we get backpack stuff ( The current implementation is a hack since we're inlining the GHC options for multiple components into one GHC invocation. That worked pretty well before backpack but now |
Looks like that |
Hi, it's a kind inquiry on what's remained to be done for it to support ghc 8.2.2? |
`stack setup` fails due to ChasingBottoms missing from Stackage We default to lts-9.20 because lts-10.0 is currently not supported by many development tools (such as intero) because ghc-mod does not yet support GHC 8.2 (DanielG/ghc-mod#900).
`stack setup` fails due to ChasingBottoms missing from Stackage We default to lts-9.20 because lts-10.0 is currently not supported by many development tools (such as intero) because ghc-mod does not yet support GHC 8.2 (DanielG/ghc-mod#900). This was tested and works with resolvers lts-10.0 and lts-9.20. Using older resolvers <=lts-7.24 causes a conflict with the package ranges specified in containers.cabal.
@HuStmpHrrr and everyone else: you can now build I have it working successfully on NixOS. |
* Add stack.yaml file to containers. `stack setup` fails due to ChasingBottoms missing from Stackage We default to lts-9.20 because lts-10.0 is currently not supported by many development tools (such as intero) because ghc-mod does not yet support GHC 8.2 (DanielG/ghc-mod#900). This was tested and works with resolvers lts-10.0 and lts-9.20. Using older resolvers <=lts-7.24 causes a conflict with the package ranges specified in containers.cabal. * Remove `stack init` step in CONTRIBUTING.md.
@mrkgnao Can you share the expression you're using? I can't seem to find a combination that works. Thanks. |
I use I then just add ghc-mod just has a couple fiddly dependencies removed (e.g.
cabal-helper is vanilla
|
@jwiegley you may have to jailbreak |
I was able to get https://github.com/jwiegley/nix-config/blob/master/overrides.nix#L249 Oddly, I need to use the |
Oh, yes, the original instructions specify that:
It confused me too. |
@DanielG It seems that everything is ready, I wonder when ghc-mod is available for GHC-8.2.1 :) |
It's less confusing if you're already used to |
Oh, hey, that makes total sense @hvr! :) |
Since
Note that I'm using this on GHC 8.2 myself, older versions of GHC are not tested yet however so don't expect them to work. |
@DanielG great news! Any hints on how to pull this into a |
@drvink After reading your comment I tried haskell-ide-engine, unfortunately I ran into this error : it seems multi-project support is not there yet! |
Also having trouble with ghc-8.2.2. Fresh install of haskell-stack (via brew) fails to With error here: https://pastebin.com/YS2GUt6n |
It doesn't have one of the most fundamental features, which is "show me the type of an arbitrary expression". Until that it isn't really usable. |
is this likely to happen any time soon, given that this issue has been open for a year and the last commit on this repo was in january? |
It does. With the VS Code plugin you can mark any given sub-expression and get the type for it ("on hover"). How to plug into that with, for example, the neovim language client is a mystery, because while you can call hover on a visual selection it fails when getting the documentation for that selection and doesn't continue after. So I would consider this not working a client issue, not an issue with HIE. |
For Haskell beginners like me who found this thread while attempting to get ghc-mod editor extensions to work (like Haskell ghc-mod for vscode) but maybe don't need the latest and greatest, downgrading to the previous Stackage snapshot worked like a charm. The stackage home page says the previous LTS release is 9.21, so I changed line 21 in stack.yaml to:
and ran
Then I added this line to my user settings in vscode:
and reloaded the editor. Success! The Using with stack section of the Atom Haskell docs was helpful. |
I'll check back in a year... |
This is a total disaster for any beginner trying to use Haskell with atom and stack. I lost half a day trying to work out what I did wrong. I've learned way too much about nix, stack and Atom, and still I can't get a basic IDE which would be expected in any other language community. I shouldn’t have to know For new users - the defaults must behave well for a beginner. How can a configuration marked LTS be released if This must work: |
@pjgoodall, for now the options are:
And no need for rage :), this is documented in atom-haskell official docs:
|
The problem is that it should either work or not rather than half work and lead someone who is new to the software down a dead end and waste hours of their life for no particular reason. If it's not going to be updated, make it not work with the newer software so people don't fall in to it's trap. Who wants to use an old version of GHC? I suggest the project be closed down if it's not going to be updated. It will just become more and more of a disaster as time goes on and waste more and more peoples time. If a proper Haskell IDE can't be had then my solution is simply not to use Haskell... Modern compilers need modern IDE's... as coding becomes more complex the tooling needs to be able to manage the complexity... else it just becomes a rats nest of BS. |
What an ungrateful attitude. The people investing their own free time to make your experience better, owe absolutely nothing to you or anyone else. You're acting as if someone on your payroll isn't doing their job properly. While I think it's obvious where your frustration comes from, this is no way to manage it. There are alternatives to ghc-mod that work with Atom. There are alternative ways of working with Haskell that don't include IDE-like tooling. And, as you said yourself, there are surely alternative languages that might make you happy. |
On the constructive side, https://github.com/haskell/haskell-ide-engine is a better interface for beginners than ghc-mod and it works well. I've packaged it for Nix: https://github.com/domenkozar/hie-nix |
Yes, haskell tooling is fundamentally broken. That has a lot of reasons, some are intrinsic to the language, some are intrinsic to GHC and the unstable API ghc-mod uses. If you want something that works (ish) and doesn't blow up on large projects (no, haskell-ide-engine is not any better), go for codex https://github.com/aloiscochard/codex and a ghci repl. That gives you a lot of things already. Otherwise you have no option except write something better. I personally don't think the ghc-mod codebase is worth maintaining. Too much legacy code and no one really understands it anymore. But if you want someone to fix it, better provide help or donations. |
@Aphexus I do sympathize with your frustration. I have had my share in the past as well. It took me many hours to understand what the problem is, and how to fix it, and just like you I regret that it costs so much time. That being said, I do not agree with the voice you give your frustration. Everyone involved with this project and every participant in this discussion (and many other people as well!) actually do care about these problems. Speaking with hurtful tone can damage the spirit that brought forth such wonderful tools as this one. @LukaHorvat Actually, I do think there are ways to manage these frustrations. The main issue I see is a mismatch between expectations of users of editor plugins and, well, reality. Many users (rightly) expect these plugins to just work. Most do not dig through documentation first (I'm not sure, but it could very well be true that I discovered the relevant line in the atom-haskell documentation only after many days, or even weeks). In the case of ghc-mod, the naive approach leads to compile errors, and then perhaps confusing internet search results. Could users perhaps be notified earlier of the way to success? An easy workaround for GHC 8.2 support not existing is using an earlier GHC version, which is easily done by using lts-9.21 or earlier. Would it be possible to have this information be a prominent part of the compile error? Editor plugins could maybe help as well, by giving the same advice. Not sure how feasible this all is though. |
There have been ghc-mod patches/repos that have tracked current GHC releases for a while now. Regardless of what anyone’s “tone” might be, the frustration is understandable, as the least @DanielG could do would be to update the README to point people to them if he’s no longer interested in maintaining ghc-mod instead of leaving people to hunt fixes for the past ~2 years. |
Another interesting actively developed and supported project is Intero -
https://github.com/commercialhaskell/intero
It works with most GHC versions and it’s interactive. Currently it works
with latests GHC. Haskell is really good language to try! You just need
right setup. For older GHC versions ghd-mod sandboxed with Stack for the
proper GHC version worked really well. Now for latest GHCs you need either
HIE or Intero. If you like console based programming, you could just open
GHCi as a separate window and learn its commands via :help command or
plenty of lectures in YouTube.
Cheers!
На пт, 28.12.2018 г., 15:12 ч. Mark Laws <notifications@github.com> написа:
… There have been ghc-mod patches/repos that have tracked current GHC
releases for a while now. Regardless of what anyone’s “tone” might be, the
frustration is understandable, as the least @DanielG
<https://github.com/DanielG> could do would be to update the README to
point people to them if he’s no longer interested in maintaining ghc-mod
instead of leaving people to hunt fixes for the past ~2 years.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#900 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFxXhrlKWxYaUfiwJ7-UltrdPROlNolBks5u9hjOgaJpZM4OjYEd>
.
|
@DanielG just to clarify, my previous remark was not meant to suggest that you've been negligent or an absentee maintainer, but I think people would appreciate it greatly if you could indicate either in the relevant issue threads and/or the README that there exists a branch in your own repo that works with GHC 8.6.2, not to mention the branches that have existed for previous GHC versions as well. All of them have worked without issue for me once I discovered they existed, so even if you don't want to merge them for some reason, letting people know that they exist would at the very least reduce the number of entitled freeloaders (like myself :)) demanding hot 0-day ghc-mod warez. |
@tsabirgaliev Frustration - not rage. But it may get that way ;-) Its all very well for people with deep knowledge of a system to imagine beginners can survive on their crumbs. But it ain't so. I've been programming a long time and the GHC ecosystem is one of the crankiest I've seen. Try videoing - lets say a java programmer of a couple of years - trying to get an IDE for GHC going. Yes and I've tried vs-code, which normally is fairly likeable - it blows up with errors that I've tried to fix. Which of the probably 73 plugins are compatible with each-other? What prerequisites do they need from Linux? INSTALLING BINARY DEPENDENCIES :-)) I've been trying to get comfortable with Haskell for months. It's a beautiful language but I just get fed-up with trying to get a stable development environment. And no, I'm not going to use Emacs. Going to emacs from Smalltalk is like poking your own eyes out. Going to file-based development is enough punishment. I tried atom-haskell after a long trail of broken development configs, because it looked like it was going to make a decent effort to get the pre-requisites sorted, and had a reasonable list of new-world features. If you want a language to prosper, you need to make the cost of entry lower than the near-term joy gained by using it. xx |
@pjgoodall -- I get your frustration, but don't forget Haskell's motto: avoid success at all costs (by SPJ), so comparing it to Java is not fair )) |
@tsabirgaliev |
Guys, ghc-mod is not an official project. It has no affiliation with the GHC or the language developers. These are community complaints that partly don't really belong in this issue tracker. Your options are:
|
ghc-mod is causing tears to stain keyboards everywhere. For general configuration I think I like nix + stack, but have had struggles with that too, about to retry. |
haskell-ide-engine, intero, dante and codex. Only the last one works with non-trivial projects. All others blow up your memory (haven't tried dante, because it's emacs only). If you're a beginner, memory might not be a problem. |
@hasufell |
I've seen announcement in haskell-cafe of a fork that works in all ghc-8.* versions: https://github.com/kazu-yamamoto/hhp |
Thanks everyone... |
Please note ghc-mod (as a development tool) is no longer supported: https://github.com/DanielG/ghc-mod#legacy. I'm going to be working on refining our software-stack[1] for use with haskell-ide-engine instead. Especially working on [1]: cabal-helper+ghc-mod(lib)+haskell-ide-engine(tool) |
There seems to have been some attempts to get ghc-mod working with 8.2.1; curious what the status of that work is. Thanks for this great software; now that I upgraded to 8.2.1, I'm really missing it!
The text was updated successfully, but these errors were encountered: