-
Notifications
You must be signed in to change notification settings - Fork 151
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
cached modules cause problems due to changed filepath #107
Comments
This is more generally because k's caching relies on Object.equals which was not implemented to compare attributes. We have similar problems with the integrity of the cache at compile time. The solution is to compare attributes when caching, but it might take some effort to get everything to work properly when we make the change. The workaround for now is to delete the kompiled directory and recompile the definition. I will look into fixing this when I get back to the office next week. |
I was not able to reproduce this behavior; can you provide me with a sequence of steps that you can reproduce the issue with if you want this resolved? |
I work with klab and can give you a step by step example where it fails. Best way to reproduce it is to talk to @ehildenb:
the path comes directly from here |
KLab's cacheing (and K's) has changed significantly since this issue was opened, so it's not likely we can reproduce it now. If it's still an issue @mhhf feel free to re-open with an example of the problem on latest K/KEVM/KLab. |
k's java-backend caches compiled modules including the filepath to that module across executions. If now the module is compiled again from a different location without being changed the old filepath is used through the execution. Which causes problems if the old file is deleted.
A solution could be an additional flag which prevents k from caching compiled modules across executions or k rebuilding modules if its path changed.
The text was updated successfully, but these errors were encountered: