-
Notifications
You must be signed in to change notification settings - Fork 45
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
feat: use lake serve #97
Conversation
…l lean client shutdown, we don't know at that point that lake failed to run.
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.
Otherwise lgtm. Let's wait for the lake version bump to land in lean and check that the integration works as expected, then merge.
Co-authored-by: Gabriel Ebner <gebner@gebner.org>
When will that be, I don't see any Lake PR that is removing the "pre" specialDesc label... |
@lovettchris my hope is to get it done this weekend, now that I have finished with other obligations that had been occupying my time. |
@gebner I merged this with master, but it was a nasty merge, so will need thorough testing. |
@gebner - another tricky merge with master. We both changed ensureClient to take a Uri, but the new version also returns a boolean telling caller if this was a new client or a cached client, needed in the implementation of installChanged. So anyway, I tested it on a multi-workspace situation and it seems to work, the latest build of Lean now has "Lake 3.0.0" and so lake is now showing up in the ps trace, and you can mix and match, here's a multi-workspace with one using older version of lean so it's running "lean --server" directly, while the other is using Lake. Nice.
|
I am seeing one interesting warning when I remove a folder from my multi-folder workspace:
Do you know what LSP is talking about? |
@lovettchris : according to the LSP spec, after the client sends a |
thanks, didn't know about that handy constructor. Co-authored-by: Gabriel Ebner <gebner@gebner.org>
@lovettchris A general note: In |
…an4 into clovett/lake_serve
Add validation code to selectToolchain to ensure the path specified looks right, with graceful handling if user provides the 'bin' folder instead of the parent folder.
Done. But in testing this things are going a bit wonky, I tried debugging it but got stuck, so I would love your help. It seems now that when I use SelectToolchain to select a different version, or a custom path, the lean server restarts no problem, I get "running" state and the pstree shows the right version of lean.exe is running, but any change to a .lean source file returns an error saying:
Here are the log files for the newly restarted lean server (started with lake serve): I have no idea why a newly created lean client things the file is closed. It is not closed... Interestingly, if I do a |
|
Indeed, re-applying the changes on top of #117 solved the problem. |
See Zulip Discussion
Proposal, replace the following setting:
![image](https://user-images.githubusercontent.com/18707114/148602700-f3240f36-9fb9-49bc-8cb6-b480c2f182fe.png)
With:
![image](https://user-images.githubusercontent.com/18707114/148603426-edc41ad7-c308-4cbe-84ad-1b7bdd5f7b77.png)
Then the rules for using
lake serve
would be:lake
lakefile.lean
in the current workspace root? If not don't uselake
lake serve
with optional +version if there's a workspace override in effect.lake serve -- args
fails fall back onlean --server
.