You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* ShakeSession and shakeRunGently
Currently we start a new Shake session for every interaction with the Shake
database, including type checking, hovers, code actions, completions, etc.
Since only one Shake session can ever exist, we abort the active session if any
in order to execute the new command in a responsive manner.
This is suboptimal in many, many ways:
- A hover in module M aborts the typechecking of module M, only to start over!
- Read-only commands (hover, code action, completion) need to typecheck all the
modules! (or rather, ask Shake to check that the typechecks are current)
- There is no way to run non-interfering commands concurrently
This is an experiment inspired by the 'ShakeQueue' of @mpickering, and
the follow-up discussion in mpickering/ghcide#7
We introduce the concept of the 'ShakeSession' as part of the IDE state.
The 'ShakeSession' is initialized by a call to 'shakeRun', and survives until
the next call to 'shakeRun'. It is important that the session is restarted as
soon as the filesystem changes, to ensure that the database is current.
The 'ShakeSession' enables a new command 'shakeRunGently', which appends work to
the existing 'ShakeSession'. This command can be called in parallel without any
restriction.
* Simplify by assuming there is always a ShakeSession
* Improved naming and docs
* Define runActionSync on top of shakeEnqueue
shakeRun is not correct as it never returns anymore
* Drive progress reporting from newSession
The previous approach reused the shakeProgress thread, which doesn't work anymore as ShakeSession keeps the ShakeDatabase open until the next edit
* Deterministic progress messages in tests
Dropping the 0.1s sleep to ensure that progress messages during tests are
deterministic
* Make kick explicit
This is required for progress reporting to work, see notes in shakeRun
As to whether this is the right thing to do:
1. Less magic, more explicit
2. There's only 2 places where kick is actually used
* apply Neil's feedback
* avoid a deadlock when the enqueued action throws
* Simplify runAction + comments
* use a Barrier for clarity
A Barrier is a smaller abstraction than an MVar, and the next version of the extra package will come with a suitably small implementation:
ndmitchell/extra@98c2a83
* Log timings for code actions, hovers and completions
* Rename shakeRun to shakeRestart
The action returned by shakeRun now blocks until another call to shakeRun is made, which is a change in behaviour,. but all the current uses of shakeRun ignore this action.
Since the new behaviour is not useful, this change simplifies and updates the docs and name accordingly
* delete runActionSync as it's just runAction
* restart shake session on new component created
* requeue pending actions on session restart
* hlint
* Bumped the delay from 5 to 6
* Add a test for the non-lsp command line
* Update exe/Main.hs
Co-authored-by: Moritz Kiefer <[email protected]>
0 commit comments