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
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.
The text was updated successfully, but these errors were encountered:
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)
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.
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:
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.
The text was updated successfully, but these errors were encountered: