Heads up: ghc-mod(i) must be run in project root directory

[DanielG]

Hey,

This might be a breaking change depending on how you handle this now. You need to call ghc-mod root to get the project root directory, and start any other commands in that directory. We unfortunately have to push this to the frontend side because we can't just fork() on windows to work around it.

[DanielG]

See https://github.com/kazu-yamamoto/ghc-mod/commit/56902bfe2d5ef7910577d54c9269d758fe770e3e

[lierdakil]

Thanks for the heads up. How does ghc-mod root work though? Especially with non-cabal projects? Can I possibly emulate it?

And for the reference, what race conditions do you mean? I'm pretty sure chdir should "just work"... 15 сент. 2015 г. 5:01 пользователь "Daniel Gröber" notifications@github.com написал:

See kazu-yamamoto/ghc-mod@56902bf https://github.com/kazu-yamamoto/ghc-mod/commit/56902bfe2d5ef7910577d54c9269d758fe770e3e

— Reply to this email directly or view it on GitHub https://github.com/atom-haskell/haskell-ghc-mod/issues/50#issuecomment-140252951 .

[DanielG]

You really don't want to emulate it you'd have to redo all the logic in Cradle and keep it consistent with what we're doing. You only need to call it once per file and it doesn't incur much overhead since it's literally just traversing the directory hierarchy a bit.

Maybe if the project type stuff was handled a bit more explicitly we could do this another way but as it stands I have to do it this way for (semi-)backwards compatibility.

ghc-modi/legacy-interactive has a second thread that generates the symbol table on start up, that needs to run in a GhcModT context so we have to use the run* function which does chdir internally. Now we have two threads mutating the working directory -> classic shared state fuckup.

[lierdakil]

Problem is, older versions of ghc-mod lack 'root' command, so for the sake of consistency I was thinking about emulating/reimplementing it. If it's very complicated, then it's easier not to. 15 сент. 2015 г. 15:35 пользователь "Daniel Gröber" < notifications@github.com> написал:

You really don't want to emulate it you'd have to redo all the logic in Cradle and keep it consistent with what we're doing. You only need to call it once per file and it doesn't incur much overhead since it's literally just traversing the directory hierarchy a bit.

Maybe if the project type stuff was handled a bit more explicitly we could do this another way but as it stands I have to do it this way for (semi-)backwards compatibility.

ghc-modi/legacy-interactive has a second thread that generates the symbol table on start up, that needs to run in a GhcModT context so we have to use the run* function which does chdir internally. Now we have two threads mutating the working directory -> classic shared state fuckup.

— Reply to this email directly or view it on GitHub https://github.com/atom-haskell/haskell-ghc-mod/issues/50#issuecomment-140373747 .

[DanielG]

Oh, right. Well the old versions have rather predictable behavior. I thought you want to replace the call to root for newer versions too. Basically just look for a cabal file starting from the directory containing the file you want to pass to ghc-mod. If you find a cabal file the directory containing that is the project directory. If not do the same thing for a cabal.sandbox.config file and use the directory containing that as the project directory if you find one. Otherwise just use the directory containing the file as the project directory.

Though I think versions before 5.3 didn't care about the working directory at all so you might get away with just starting ghc-mod wherever with those versions and 5.3 already has the root command so it should be fine.

BTW. 5.4.0.0 has been release now so brace yourself ;)

[edsko]

(Just a remark that the cabal backend for ide-haskell does the same thing -- look for the .cabal file and run cabal there.)

[lierdakil]

Okay, so I think I managed to conform to this requirement with 0.9.1. For posterity, if there are any issues, feel free to open separate ones.