prusti-assistant icon indicating copy to clipboard operation
prusti-assistant copied to clipboard

Add persistent caching

Open JonasAlaif opened this issue 3 years ago • 9 comments

JonasAlaif avatar Jan 20 '22 19:01 JonasAlaif

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.

fpoli avatar Jan 20 '22 20:01 fpoli

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.

JonasAlaif avatar Jan 21 '22 08:01 JonasAlaif

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.

fpoli avatar Jan 21 '22 09:01 fpoli

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.

fpoli avatar Jan 21 '22 09:01 fpoli

Any idea why the CI fails?

JonasAlaif avatar Jan 21 '22 13:01 JonasAlaif

Any idea why the CI fails?

Mmm, not really. Does it pass locally?

fpoli avatar Jan 21 '22 16:01 fpoli

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.

JonasAlaif avatar Jan 21 '22 17:01 JonasAlaif

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?

JonasAlaif avatar Jan 21 '22 17:01 JonasAlaif

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.

fpoli avatar Jan 21 '22 17:01 fpoli