Major steps required (Roadmap) #1
Comments
|
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. Caveats: we had to wrap each plugin lib (hlint, brittany, floskell, etc) or sets of plugins in a |
|
@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. |
|
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??? |
|
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). |
|
@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. |
|
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. |
|
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 |
|
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 |
|
Just dumping this here, thoughts on range formatting. haskell/haskell-ide-engine#1602 (comment) |
|
Sounds like a perfect use case for dynamic linking @jneira @ndmitchell |
|
Another question: could we continue using the hie solution to handle several ghcs using a wrapper? 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. |
|
@NightRa coming from the jvm world, where it is the default way to go, i think so. |
|
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. |
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. |
|
@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. |
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. |
|
What is "Implicit Configuration" I guess "Settings", menus and buttons? |
|
@Anton-Latukha if refers to the "automatic" configuration to start a ghc session with |
I'd done some components with an idea called Hosting Based Interfacing, basically you re-organize fine-grained API calls into coarse-grained, business-oriented, parametric pieces of peer script, send it to a remote process for (hosted) execution, the result (naturally asynchronous and in free form) is conveyed with similar pieces of such script back to the originating peer process. In context here it means to have a single GHC session hosting process, receiving and executing scripts from various plugin processes, those scripts help themselves to grab necessary (thus amount-wise, greatly reduced than raw GHC api transcription payload) data and do scripting back. This technique won't reduce the overall complexity, actually, writing a single piece of code that would run interleaved among 2 or more processes, is confusing and uncomfortable at times. But it is especially effective for realtime communicating services / clients over WAN, insensitive to the delay of double latency imposed by the round-trip of request/response cycles, which may more because of the async nature, another significant optimization is that, per api-call marshal/unmarshal is avoided, the total payload over-wire is greatly reduced. Hosting Based Interface won't make it easier or simpler for multiple plugins to share a common GHC session, but may help developing a minimal thus hopefully more stable contract for what artifacts (i.e. constants, procedures etc.) to be hosted at a single GHC session process, while leaving the plugin processes enough flexibility and space of imagination to script the transactions to accomplish their jobs. |
//cc @alanz |
jneira
added
the
status: needs info
Perhaps wait to see if there is any renaming of hie-bios? I get the impression the word "hie" is now an anachronism, and confuses newcomers. I think that ship has sailed though, it is pretty much baked in all over the place. |
|
And for the record, I agree that the schema belongs to hie-bios |
|
No preference for naming from me. But this sets a nice dependency order: the patch for stack/cabal-install ought to be essentially (1) import lib, (2) fill in the data structures, (3) provide command that dumps the data structure to stdout. There might be some back and forth if there's a field I can't provide from Stack, those could be I don't have much bandwidth for tooling anymore. But I can get low overhead changes into Stack like this. |
|
Nice, @chrisdone thanks for take care. |
|
I like the plan, I wasn't aware that we are actually this close to have tooling support in cabal and stack 😮. For the implementation plan in cabal, I am not sure they will add new dependencies to it, such as @chrisdone I missing some information, such as path to EDIT: BTW, I volunteer/want to maintain a library such as |
|
We already are using ghcide master |
|
@fendor out of curisoity, have you the opportunity of make some progress about the cabal/stack integration? |
|
@jneira Unfortunately, not at all. I have been occupied with other stuff :( |
|
no worries, maybe we can reactivate it via the next Gsoc? |
|
That is definitely a good idea! |
|
Regarding module graph: the hiedb branch was merged. |
|
@andys8 thanks for noting it, checklist updated |
|
I've labeled it as Eligible for gsoc 2021 due to
It has not a dedicated issue |
|
Plugin architecture check done! |
|
|
|
I can apply the stack command when needed, but what’s the latest summary of the JSON format? It’s a year and a half later... 😳 |
|
"las cosas de palacio van despacio" 😝 maybe the JSON format is already specified, even informally, @fendor? |
|
As I think I thought, maybe it is here just too much noise. |
|
I love this venerable issue with the great initial @alanz vision of how could be the hls path.
|
2020-09-29 Update (@jneira)
hiedb#704show-build-infofor cabal-install cabal#7478show-build-info) hie-bios#269 (comment)type Foo = Foofor some ghc versions #352 and Space Leak #386 (and Memory usage #802 from ghcide)The text was updated successfully, but these errors were encountered: