-
Notifications
You must be signed in to change notification settings - Fork 206
Add window/progress reporting for typechecking #1190
Conversation
lf <- lift $ asks ideEnvLspFuncs | ||
withIndefiniteProgress' lf t f | ||
|
||
withIndefiniteProgress' :: MonadIO m => Maybe (Core.LspFuncs Config) -> T.Text -> m a -> m a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't get this to type check with withIndefiniteProgress = lift . withIndefiniteProgress
, this is a workaround. Open to suggestions to make this nicer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides tests, I think it would be nice to have examples on how to integrate them into a plugin. E.g. some plugins might want to be able to report progress as well. Will that be possible?
Otherwise, great job, the diff is clean and easy to follow!
@@ -344,14 +344,15 @@ data IdeEnv = IdeEnv | |||
} | |||
|
|||
-- | The class of monads that support common IDE functions, namely IdeM/IdeGhcM/IdeDeferM | |||
class Monad m => MonadIde m where | |||
class MonadIO m => MonadIde m where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess IO is needed to actually send the message back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
What changes are needed for the vscode extension? How portable is this to other clients? |
Mainly updating the client library and enabling the proposed features, haskell/vscode-haskell#150 |
Yup! Since |
Possibly the liquid haskell one |
haskell-ide-engine/src/Haskell/Ide/Engine/Plugin/Liquid.hs Lines 123 to 125 in 0bdb86a
|
|
||
withProgress' :: MonadIO m => Maybe (Core.LspFuncs Config) -> T.Text -> ((Core.Progress -> m ()) -> m a) -> m a | ||
withProgress' lspFuncs t f = | ||
let mWp = Core.withProgress <$> lspFuncs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it be better to pass the actual Core.withProgress
instead of getting it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the passed in function could be of the form a -> IO ()
, so obviating the need for MonadIO
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lorenzo currently there is the possibility that lspFuncs returns Nothing
, so it would have to be a Maybe
, I think this is due to the existence of the JSON transport. I think this also asks the question, should we just give plugins full access to lsp funcs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either give full access, or make the progress reporting function available to them by default, as in my earlier comment. I think we already do something similar with accessibility to the VFS stuff. I would have to take a look though.
I am very much in favour of constraining what plugins/monads can do, so we do not get weird stuff happening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that makes sense
-- 'withProgress' @title f@ wraps a progress reporting session for long running tasks. | ||
-- f is passed a reporting function that can be used to give updates on the progress | ||
-- of the task. | ||
withProgress :: T.Text -> ((Core.Progress -> m ()) -> m a) -> m a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be ore clear to name this withProgressReport
One thing we noticed on IRC is that the type of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
tid <- liftIO $ async $ generateDiagnosics cb uri file | ||
let progTitle = "Running Liquid Haskell on " <> T.pack (takeFileName file) | ||
tid <- withIndefiniteProgress progTitle $ | ||
liftIO $ async $ generateDiagnosics cb uri file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't right. The progress report needs to go inside the call to async
and if you do that, you'll discover that the types for withIndefiniteProgress
are not quite right still..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You’re right, this completely slipped by me! I was testing it by adding a threadDelay 10000000
…
I don't think this is quite right yet. It's weird that the |
See mpickering@3b41a98#diff-5c94e6cdb53262cd6976feddb9d4cedfR126 and mpickering/haskell-lsp@f5e47d9 For how I think this should be fixed. |
You're right: I got ahead of myself and was thinking of |
Co-authored-by: Matthew Pickering <[email protected]> Co-authored-by: Luke Lau <[email protected]>
…into window-progress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks like a few things need cleaning up.
You should use the |
@mpickering |
@bubba there are now conflicts here |
…into window-progress
Will this be merged in time for #1227 ? |
Probably not. I need to land the release tonight, as I am traveling the
next two days, so can't predict time to pay attention.
…On Wed, 01 May 2019, 21:36 Luke Lau, ***@***.***> wrote:
Will this be merged in time for #1227
<#1227> ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1190 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADEAB6JTDGFBEWX6Y6E3B3PTHWMFANCNFSM4HHPINVQ>
.
|
@bubba @mpickering Can you guys refresh this so we can merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job.
Todo
Depends on a couple of tweaks with the VS code extension