Add persistent caching
Two quick notes:
- I don't think we can easily have a per-crate cache, because we don't use a per-crate server. I'd store the cache under the global storage path of the extension, in the (existing) folder of the configured ~~toolchain~~ build channel.
- When deleting the cache file, I think we have to stop the server before and re-start the server after.
Thanks! Very good points, the former I realised as I was trying to implement the per-crate cache, I now use (makes it infinitely easier to delete the cache as well, since we don't have to go looking for the file):
export function getCachePath(context: vscode.ExtensionContext): string {
return path.join(context.globalStoragePath, "cache.json")
}
Should I additionally put the cache.json inside an extra directory?
For the latter, I hadn't realised that but yes will definitely need to do that. I'm still having trouble getting the Prusti server to even save the cache on exit - using SIGTERM instead of KILL doesn't seem to help.
export function getCachePath(context: vscode.ExtensionContext): string { return path.join(context.globalStoragePath, "cache.json") }
I'd use different cache files for different build channels (e.g. cache-{buildChannel()}.json?):
https://github.com/viperproject/prusti-assistant/blob/8c12156a2298fb99227c6a319998025577d79114/src/config.ts#L12-L16
You can look it up with:
https://github.com/viperproject/prusti-assistant/blob/8c12156a2298fb99227c6a319998025577d79114/src/config.ts#L21
Also, I'd move the getCachePath to the config.rs file (and call it cachePath). We could then let the user override its location (independently from the build channel) in the future.
For the latter, I hadn't realised that but yes will definitely need to do that. I'm still having trouble getting the Prusti server to even save the cache on exit - using SIGTERM instead of KILL doesn't seem to help.
To understand if it's a Prusti or Prusti-assistant issue, does the server save the cache if you manually start and terminate it from the command line? If that's too hard to fix, we can add a POST /save entry point to the API of the prusti-server, such that we can call that from the IDE before stopping the server.
Any idea why the CI fails?
Any idea why the CI fails?
Mmm, not really. Does it pass locally?
Not when I run the tests no - it gets stuck on Checking Prusti dependencies and warns that activating the extension failed because Prusti server took more than 10 seconds to start.
But when I have the project open in VSCode and run it with F5 it works just fine.
Ah, I've found the answer:
[stderr] thread '[stderr] main' panicked at 'environment variables contains unknown configuration flag: “cache_path”', prusti-common/src/config.rs:168:9
Is there any solution to this, other than waiting for caching to be included in a Prusti release?
I think it's quicker to do if (buildChannel() != BuildChannel.LatestRelease) { /* set PRUSTI_CACHE_PATH */ }.
I'd wait a few weeks before doing a release, just to test the changes for a while.