Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge into master #48

Closed
23 of 26 tasks
fendor opened this issue Nov 14, 2019 · 21 comments
Closed
23 of 26 tasks

Merge into master #48

fendor opened this issue Nov 14, 2019 · 21 comments

Comments

@fendor
Copy link
Collaborator

fendor commented Nov 14, 2019

This issue tracks the progress to finally merge hie-bios into https://github.com/haskell/haskell-ide-engine.
It consists of all issues that need to be worked on or PRs that need to be merged before we are ready to merge. People may be assigned to the issues. These assignments are naturally non obligatory ;D. Also, work-stealing is promoted if you run out of tasks!

This list is meant to be thourogh and complete. If something is missing, we will expand this list. It may look frightening but almost each of these issues is minor. We are almost done! 🐳

@bubba, @alanz, @mpickering, @jneira, @power-fungus, @lorenzo

@mpickering
Copy link
Owner

Can we assign people to each of these subtasks? Feel free to assign me to whatever you think I am best suited for.

@alanz
Copy link

alanz commented Nov 14, 2019

I will take on the HaRe tests, and getting haskell-lsp prepared for release.

@lukel97
Copy link
Collaborator

lukel97 commented Nov 17, 2019

Check, if the user has the build-tools on the Path, before selecting a project type

I can take a look at this @fendor

@lukel97
Copy link
Collaborator

lukel97 commented Nov 17, 2019

An issue that's affecting my particular setup (I wouldn't let this block the release though) is that for cabal projects with with-compiler set to a different compiler than the ghc on the path, hie-bios fails as it just calls regular ghc. @dxld mentioned on IRC that c-h does return this information apparently so we could make use of this?

@fendor
Copy link
Collaborator Author

fendor commented Nov 17, 2019

The ghc on the path is in my opinion an orthogonal problem to cradle selection. This can ultimately only be solved in hie-bios itself.
I will split it up into separate issues, there we can discuss what I meant with it.

@jneira
Copy link

jneira commented Nov 18, 2019

I'm not sure if catching ghc exceptions would fix #32 cause i still dont know why hie doesnt respond within the dhall-haskell (and it works in linux but no in my windos systems). Anyway i think we shouldnt block merging if it is not fixed (i'll test it again with the last merged version just in case).
But it definitely could fix #47 and maybe #27. (#47 is already showing the error in vscode, the problem is with cabal_macros.h)

@jneira
Copy link

jneira commented Nov 18, 2019

Check that stack based projects also work with the implicit configuration

For check that we could create a explicit hie.yaml with cradle: {stack}, right?

@jneira
Copy link

jneira commented Nov 18, 2019

Building the branch is failing for me with stack due to -Werror=unused-imports:

haskell-ide-engine>     The import of `Haskell.Ide.Engine.Cradle' is redundant
haskell-ide-engine>       except perhaps to import instances from `Haskell.Ide.Engine.Cradle'
haskell-ide-engine>     To import instances alone, use: import Haskell.Ide.Engine.Cradle()
haskell-ide-engine>   |
haskell-ide-engine> 8 | import           Haskell.Ide.Engine.Cradle (findLocalCradle)
haskell-ide-engine>   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
haskell-ide-engine>
haskell-ide-engine> D:\ws\haskell\haskell-ide-engine\app\MainHie.hs:19:1: error: [-Wunused-imports, -Werror=unused-imports]
haskell-ide-engine>     The import of `System.FilePath' is redundant
haskell-ide-engine>       except perhaps to import instances from `System.FilePath'
haskell-ide-engine>     To import instances alone, use: import System.FilePath()
haskell-ide-engine>    |
haskell-ide-engine> 19 | import           System.FilePath ((</>))
haskell-ide-engine>    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Fixed with #53

@fendor
Copy link
Collaborator Author

fendor commented Nov 18, 2019

Check that stack based projects also work with the implicit configuration

For check that we could create a explicit hie.yaml with cradle: {stack}, right?

I meant more manual testing. The ci is actively using only stack cradles, e.g. cradle: { stack: {}} .
I am thinking of #32 for example.

@jneira
Copy link

jneira commented Nov 18, 2019

Check that stack based projects also work with the implicit configuration

For check that we could create a explicit hie.yaml with cradle: {stack}, right?

I've tested in a simple project:

  • With cabal.project and stack.yaml the cradle Cabal-Helper-Cabal-V2 is succesfully loaded
  • With hie.yaml = cradle: {stack} the hie-bios stack cradle is succesfully loaded (with cabal.projectpresent)
  • With stack.yaml and no cabal.project the cradle Cabal-Helper-Stack is succesfully loaded

@lukel97 lukel97 pinned this issue Nov 18, 2019
@jneira
Copy link

jneira commented Nov 21, 2019

Not sure if it worths open an issue but hie doesnt create/use C:\TEMP\hie.log if the vscode log location option is empty. If i set the option it works (tested by @reactormonk and myself).

@lukel97
Copy link
Collaborator

lukel97 commented Nov 21, 2019

@jneira for the vscode extension I changed it to go the output window by default when no log file is set, since I thought it was a bit confusing to have logs going to two separate places!

@jneira
Copy link

jneira commented Nov 21, 2019

Oh, ok, agree it is better, but the output of the two previous sources are being merged in the same output window now?

@lukel97
Copy link
Collaborator

lukel97 commented Nov 21, 2019

@jneira Yeah. Previously just the logm/debugm calls from hs-logger got sent to the log file. So now it’s all those calls, plus stderr and any child process stderr

@jneira
Copy link

jneira commented Dec 2, 2019

I've run the test suite in my windows 10 with persist-virtual-file and the fix for VFS keys on windows:
Results:

  • Output: https://gist.github.com/jneira/6c00a2e78a1f3083b20070b4e77257f8
  • Unit tests: two failing ones
    • HaRePlugin, hare plugin, Additional GHC API commands
  • Functional test: seven failing ones, but most of them due to slighty different output. Only two seems to be meaningful:
    • HieBios.hie-bios reports errors in hie.yaml: uncaught exception: ConduitParserException
    • TypeDefinition, type definitions, find type-definition of type def in component

Some of them are the same than the reported ones here

@jneira
Copy link

jneira commented Dec 3, 2019

#71 would fix the HieBios.hie-bios reports errors in hie.yaml: uncaught exception: ConduitParserException failing test

@alanz
Copy link

alanz commented Dec 10, 2019

I am beginning to wonder whether we should not remove HaRe from hie until after the hie-bios merge, and whatever we do with ghcide.

We do not currently have a good story for getting the project level module graph, and this means HaRe cannot work effectively. It has also been languishing for a long time waiting for underlying support, so I am not all that confident of its actual usefulness at the moment.

Thoughts?

@fendor
Copy link
Collaborator Author

fendor commented Dec 10, 2019

Which features would be disabled by it?

  • rename
  • find cross component, etc?

@alanz
Copy link

alanz commented Dec 10, 2019

I am just starting to take a look at that, as a fork off mpickering/hie-bios

@mpickering
Copy link
Owner

I have now released hie-bios-0.3.

@fendor
Copy link
Collaborator Author

fendor commented Dec 20, 2019

We made it into master!

@fendor fendor closed this as completed Dec 20, 2019
@fendor fendor unpinned this issue Dec 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants