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

Generate linkables in the Eval plugin #2295

Merged
merged 9 commits into from
Oct 25, 2021
Merged

Generate linkables in the Eval plugin #2295

merged 9 commits into from
Oct 25, 2021

Conversation

pepeiborra
Copy link
Collaborator

@pepeiborra pepeiborra commented Oct 23, 2021

The intention is to move the codegen aspect of the Eval plugin away from the Interactive session and into the ghcide build graph. This should result in a much snappier user experience and hopefully also in a less flaky test suite.

The approach used is to redefine the NeedsCompilation rule adding a dependency on the GetEvalComments rule, so that whenever a module has -- >>> comments and it's open in the editor, the NeedsCompilation rule signals that a linkable is required. This should do what we need and, as far as I can see, has now downsides.

This is the first time that we redefine a build rule in a plugin, but I've been using this trick in sigma-ide for a while now and it's safe.

@pepeiborra pepeiborra requested a review from wz1000 October 23, 2021 13:49
@wz1000
Copy link
Collaborator

wz1000 commented Oct 23, 2021

Nice! I've been wanting to implement something like this for a while. However, I there are a few downsides if I understand this patch correctly:

  1. Any comment matching the eval syntax is enough to force code generation for the file and all of its dependencies. This is a regression, as on current master the eval plugin will only compile stuff (and thus have an impact on HLS performance and memory) if it is actually invoked by the user.
    Am I correct in observing that this has the potential to regress performance for certain users? Namely those who

    1. have the eval plugin enabled
    2. have comments matching the eval syntax in their tree
    3. don't make use of the eval plugin very frequently
  2. We run codegen for all builds, for every single modification - this is wasted work if the result of the codegen isn't going to be used by the eval plugin. I imagine the typical interaction would consist of many modifications, with a few invocations of the eval plugin sparsely distributed in between. So I think the ideal scenario would be building with codegen enabled only when the eval plugin is actually invoked.

@pepeiborra
Copy link
Collaborator Author

Nice! I've been wanting to implement something like this for a while. However, I there are a few downsides if I understand this patch correctly:

  1. Any comment matching the eval syntax is enough to force code generation for the file and all of its dependencies. This is a regression, as on current master the eval plugin will only compile stuff (and thus have an impact on HLS performance and memory) if it is actually invoked by the user.
    Am I correct in observing that this has the potential to regress performance for certain users? Namely those who

    1. have the eval plugin enabled
    2. have comments matching the eval syntax in their tree
    3. don't make use of the eval plugin very frequently
  2. We run codegen for all builds, for every single modification - this is wasted work if the result of the codegen isn't going to be used by the eval plugin. I imagine the typical interaction would consist of many modifications, with a few invocations of the eval plugin sparsely distributed in between. So I think the ideal scenario would be building with codegen enabled only when the eval plugin is actually invoked.

Yes, that's right, there are some tradeoffs. Hold on, I think I know what you have in mind...

@pepeiborra
Copy link
Collaborator Author

Check now, was this still the plan?

@pepeiborra pepeiborra force-pushed the eval-plugin-linkable branch from a2e057f to c056b1d Compare October 24, 2021 14:25
@pepeiborra
Copy link
Collaborator Author

I found a bunch of other issues while testing, will extract separate PRs.

@pepeiborra pepeiborra force-pushed the eval-plugin-linkable branch 2 times, most recently from 6c83b01 to 8080777 Compare October 24, 2021 15:46
Copy link
Collaborator

@wz1000 wz1000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice. I may finally start enabling the Eval plugin for daily use.

The reasoning for the custom newness check is a bit subtle though, I think it would make sense to document it properly.

ghcide/src/Development/IDE/Core/RuleTypes.hs Show resolved Hide resolved
ghcide/src/Development/IDE/Core/Rules.hs Outdated Show resolved Hide resolved
@pepeiborra pepeiborra force-pushed the eval-plugin-linkable branch from 8080777 to 7dfc9eb Compare October 24, 2021 18:12
@pepeiborra
Copy link
Collaborator Author

Very nice. I may finally start enabling the Eval plugin for daily use.

The reasoning for the custom newness check is a bit subtle though, I think it would make sense to document it properly.

You may want to try it and see that it works for you now

When I ported https://github.com/ndmitchell/shake/pull/802/files to hls-graph, I changed the encoding of the dirty set. Instead, Dirty became a constructor in the Status union. But the databaseDirtySet stayed around accidentally, leading to some confusion.
…hen Evaluating

In addition, we tune the newness check of the redefined NeedsCompilation rule so that the generated linkables are not thrown away unnecessarily, as described in:

ndmitchell/shake#794
@pepeiborra pepeiborra force-pushed the eval-plugin-linkable branch from e98625e to b3f4e9a Compare October 24, 2021 23:47
@pepeiborra pepeiborra added the merge me Label to trigger pull request merge label Oct 24, 2021
@mergify mergify bot merged commit 229faac into master Oct 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge me Label to trigger pull request merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants