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

Major steps required #1

Open
alanz opened this issue Jan 25, 2020 · 20 comments
Open

Major steps required #1

alanz opened this issue Jan 25, 2020 · 20 comments
Labels

Comments

@alanz
Copy link
Collaborator

@alanz alanz commented Jan 25, 2020

  • Plugins
  • Implicit Configuration
  • Multi-component / package
  • stack hie-bios flag
  • cabal hie-bios flag
  • Terminal modules (module graph)
  • memory usage
@bubba

This comment has been minimized.

Copy link
Collaborator

@bubba bubba commented Jan 26, 2020

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 27, 2020

Have you considered use precompiled executables to use plugins at runtime, instead compile at runtime them? I guess they should be executed as daemons (like the ide server itself), to avoid the start process overhead.
We could use a subset (?) of lsp json format to comunicate between the ide main server and the plugin executables, to no reinvent any wheel.
This way the plugins+lsp could be even used in a isolated way from a vscode extension. In fact maybe we could distribute them as separate vscode extensions, keeping in the server only the core interface with ghc: compile errors, goto def, etc

Caveats: we had to wrap each plugin lib (hlint, brittany, floskell, etc) or sets of plugins in a executable+lsp stdio+ghc interface wrapper and distribute the precompiled executables separately.

@jneira jneira pinned this issue Jan 27, 2020
@ndmitchell

This comment has been minimized.

Copy link
Collaborator

@ndmitchell ndmitchell commented Jan 27, 2020

@jneira many plugins are going to require a GHC session. Either you can duplicate the GHC session to different processes (which is incredibly expensive in CPU terms), or marshal every GHC API call over to the GHC session (incredibly expensive in terms of communication). It would be nice if we could figure out a way that works, but I can't think of one.

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 27, 2020

Mmm i see. Thanks for sharing.

So add to the ide server a bridge between the ghc session and the plugins using a lsp-like format is not viable 😞

Still, could plugins not using the ghc session be isolated? Dont know much about each tool internals but maybe any of hoogle, hlint, liquid or any of formatters dont use a ghc session???

@ndmitchell

This comment has been minimized.

Copy link
Collaborator

@ndmitchell ndmitchell commented Jan 27, 2020

Most plugins are likely to get something from the GHC environment - the parse tree, the text after preprocessing, the names on which to run searches. Looking at HLint and formatters like Ormulu, they should be using the GHC environment (they currently build their own GHC environment, which is a bit different).

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 27, 2020

@jneira the approach fpcomplete took in their initial web-ide backend took that approach, and I understand had major issues with just sharing data between the various processes.

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 27, 2020

Plus the prospect of the kinds of issues that will be raised because people are not able to get a set of separate processes running and talking to each other is not good. Think our current stuff x 10.

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 27, 2020

Sorry if i am adding a lot of nosense but i think @mpickering mentioned a library that tried to eval haskell code at runtime than maybe could be useful: not sure if it was https://github.com/stepcut/plugins

@fendor

This comment has been minimized.

Copy link
Collaborator

@fendor fendor commented Jan 27, 2020

Out of curiosity, did you have time to touch debugger integration? Or is it too soon to talk about such a feature?

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 27, 2020

Out of curiosity, did you have time to touch debugger integration? Or is it too soon to talk about such a feature?

We had a brief conversation, which did not go anywhere in particular. I think it is something that needs to happen, sometime, but we first need to get over the initial process. Once haskell-ide is available for use, we can consider additional stuff.

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 27, 2020

Just dumping this here, thoughts on range formatting. haskell/haskell-ide-engine#1602 (comment)

@NightRa

This comment has been minimized.

Copy link

@NightRa NightRa commented Jan 28, 2020

Sounds like a perfect use case for dynamic linking @jneira @ndmitchell

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 28, 2020

Another question: could we continue using the hie solution to handle several ghcs using a wrapper?
I think it could be more beginner friendly although it has a point of friction trying to guess the ghc version used in a project.

Somewhat philosophical side note: it seems to me that ghcide is more used by (suited to?) experienced haskell developers. I think we have the opportunity and the challenge to build a tool well-balanced between beginners and more experienced haskell devs.

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 28, 2020

@NightRa coming from the jvm world, where it is the default way to go, i think so.
However i am not sure if it is widely used enough in the haskell world to not hit a lot of pain points (performance, bugs, etc, etc)

@ndmitchell

This comment has been minimized.

Copy link
Collaborator

@ndmitchell ndmitchell commented Jan 28, 2020

Dynamic linking is not a well trodden path in Haskell. I would avoid it like the plague as it's no fun for support.

The plan is to do the HIE compiling lots of binaries thing.

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Jan 28, 2020

The plan is to do the HIE compiling lots of binaries thing.

It has its own pain points especially for beginners, although i suppose they are better known and battle tested. Experience is king here (always? 😉) and absolutly trust @ndmitchell, @alanz and the surely thoughtful discussions at Bristol.
However to avoid too much (exponential?) slow static compilation combinations i would not totally abandon the alternative of break them via binaries wherever is factible. Even if we start to compile everything statically for the shake of simplicity.

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 28, 2020

@jneira As far as I am concerned, the initial effort should be to end up with an equivalent setup here as we have for hie, in terms of the wrapper and build system.

Also, to achieve parity by migrating our existing plugins.

It is not the time to try experimental stuff, I would like to see something usable ASAP.

@alanz

This comment has been minimized.

Copy link
Collaborator Author

@alanz alanz commented Jan 29, 2020

As far as I am concerned, the initial effort should be to end up with an equivalent setup here as we have for hie, in terms of the wrapper and build system.

We are getting close to this, in the sense that we have copied it over, and done a smoke test.

I think the most important feature before we can recommend it to anyone is multi-component support.

@Anton-Latukha

This comment has been minimized.

Copy link

@Anton-Latukha Anton-Latukha commented Feb 17, 2020

What is "Implicit Configuration" I guess "Settings", menus and buttons?

@jneira

This comment has been minimized.

Copy link
Collaborator

@jneira jneira commented Feb 17, 2020

@Anton-Latukha if refers to the "automatic" configuration to start a ghc session with hie-bios, using cabal-helper (or other) to get the ghc flags instead an explicit hie.yaml file: see https://github.com/haskell/haskell-ide-engine#project-configuration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.