search

atom-haskell-archive / haskell-ghc-mod

haskell-ghc-mod atom package
https://atom.io/packages/haskell-ghc-mod
MIT License
69 stars 20 forks source link

ghc-mod-5.5.0.0 not working with multi project stack.yaml #136

Closed lippling closed 8 years ago

lippling commented 8 years ago

I've the following setup:

stack.yaml:

resolver: lts-5.13

packages:
- oauth2/
- server/
- location:
    git: git@github.com:hotwirestudios/haskell-opaleye.git
    commit: ba708c17bd5aec4f1cc52f82bc61d7894bac6f48
- location:
    git: git@github.com:hotwirestudios/opaleye-trans.git
    commit: 39583daafac28575ec110f4ed162278133e9d770

When I open and save a .hs file in Atom, every package (which was installed by stack) is marked with "...could not be found..." after the import. This seems only to be the case for multi project setups. When I run atom . directly in the subdirectory it works.

I tested several things (none worked):

Using ghc-mod-5.4.0.0 seems to be a workaround:

rvion commented 8 years ago

same for me. I usually hack around this issue by creating a top level package '.' whose aim is only to import all libs from all other local packages. This way atom ghc-mod picks all libraries from local packages.

lippling commented 8 years ago

@rvion Do you have an example?

rvion commented 8 years ago

@lippling this is not a proper example, but something like that: https://github.com/rvion/ghcid-bug-repro

rvion commented 8 years ago

note that this workaround doesn't load the code for executable tagets unless you load those file in ghc-mod. if you want ghc-mod to be aware of everything, you have to put all your executable code in dedicated libraries, all of them exposing some libMain, and have single module executables like that

module Executable where
import Lib
main = libMain

then, your top level '.' package need to depends on all libraries including those wrapping executable code.

this workaround is far from ideal, but works quite okay.

as a side note, even with this technique, ghc-mod + stack doesn't play well with ghci / ghcid. so there is still a few problems to solve :/ if you have ghcid running along ide-haskell, ghc-mod will crash, and ide-haskell will stop working. (I don't this issue has been reported yet, but it is reproductible on various setup :/)

lippling commented 8 years ago

Thanks! I'll give it a try.

lierdakil commented 8 years ago

I think this issue belongs on ghc-mod repo https://github.com/DanielG/ghc-mod/issues Not sure I can do anything on this end. /cc @DanielG

anton-dessiatov commented 8 years ago

I've managed to track down this issue to a bug in an isDirectory function of atom-haskell-utils module.

The line at the following URL seems to work unreliably: https://github.com/atom-haskell/atom-haskell-utils/blob/fc01220c2afc4379181afbd631b70777d1d215c1/src/util.coffee#L8

It says

    when (dir instanceof Directory) or (dir instanceof File)

making use of JavaScript instanceof operator. I'm by no means an expert in JavaScript, but debugging clearly shows that for some directories this expression returns false despite console dump tells that dir is an instance of Directory.

This means that getRootDir function from the same module always takes getRootDirFallback route and uses atom project root (and not the directory where .cabal is located) as a startup directory for ghc-mod.

I've replaced that line with

    when (dir.getPath)

and it fixed the problem for me.

lierdakil commented 8 years ago

Okay then... instanceof fails miserably between frames, but I assumed it should be fine in Atom. Apparently not. Oh well. I switched to duck typing, so let's now hope for the best.

MaxDaten commented 8 years ago

It works for me now with ghc-mod-5.5.0.0 :)

lierdakil commented 8 years ago

This should hopefully be resolved to a somewhat satisfactory degree. If not, please open new issues.