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

Compile All Frege Files in Workspace On Initialise #48

Open
tricktron opened this issue Sep 16, 2022 · 1 comment
Open

Compile All Frege Files in Workspace On Initialise #48

tricktron opened this issue Sep 16, 2022 · 1 comment

Comments

@tricktron
Copy link
Owner

tricktron commented Sep 16, 2022

According to the language server protocol, language features should be independent of whether a text document is open or closed. The Frege LSP, however, currently only works for opened Frege files (the didOpen notification is needed to trigger a compilation of the opened files and dependencies to set up the in-memory model hashMap <URI,Global>).

To satisfy this requirements, we can trigger a compilation of all Frege files (read from disk) in the workspace on initialise. As a result, we have our in-memory hashMap <URI,Global> correctly set up to answer language feature requests sensibly.

Since the Frege compiler has a great built-in cache mechanism, this change only results in a major workload increase when a project with many Frege files is opened for the first time because all files will be compiled. In all subsequent cases of opening the same Frege project again, the cache will be used and only changed/newer Frege files will be compiled.

However, the Frege compiler's caching mechanism is too sophisticated for the Frege LSP at the moment: It only recompiles a module if:

  • There does not exist a corresponding class file in the target path, or the source file is newer than the class file.
  • Any of the dependencies of a module needs to get recompiled.

Currently, I do not clean up the class file output directory. As a result, if you open a Frege project for the second time, then the Frege compiler will not compile anything. Consequently, the Frege LSP cannot initialise the hashMap <URI,Global> and all language feature requests won't return any sensible results. In other words, we have an out of sync situation of the Frege compiler and the Frege LSP's in-memory model.

As a workaround, you can just save the opened file to trigger the Frege compiler because (although there are no changes to the source file), the source file is newer than the class file.

@tricktron
Copy link
Owner Author

tricktron commented Sep 16, 2022

After some thinking:
The caching solution only works if there is a way to persist the hashMap <URI,Global> data structure. Without a persistent solution, we need to start from scratch with two possible approaches:

  • Always compile all Frege files on startup (run in background, show progress bar)
  • Compile only on demand: Add a compile call before every language feature request. I decided against this because changes to the source files should drive the compilation. See Think about Splitting Compile From Language Feature Step #27.

Thoughts on the caching solution:
Why not write the hashMap <URI,Global> to disk on shutdown and read it on initialise? For this to work, we need serialisability. The Java HashMap data type is serialisable, so this might work. However, I don't know if the values, e.g. the Frege Global data type needs to be serialisable as well.

This would sync the Frege compiler's state with the hashMap <URI,Global> in memory model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant