-
Notifications
You must be signed in to change notification settings - Fork 12
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
Persisting the analysis state #13
Comments
Analyses can now be (de-)serialised. (See commit 89d5a7f) |
I have tried unsuccessfully at using other serialization frameworks such as jackson, borer, and circe. The main issue stems from our open design. Given the lack of documentation and cryptic errors from each serialization library, I wanted to go in baby steps. Abstract values make the most sense to have serialized first, but:
So doing it in baby steps is not possible, and this requires a careful analysis to have a clean implementation |
Having this feature would greatly improve debugging, as it permits running an analysis once and inspecting the results afterwards in different manners, without having to rerun the analysis when one wants to inspect another aspect of the result. This could also help with debugging other code, such as benchmarking code (e.g., for the precision evaluation), when unexpected results are obtained. |
Currently, it is not possible to save the state of an analysis to a file, and to restore it afterwards. This hampers (performance) testing and debugging, especially for incremental analyses: to test an incremental update, a full initial analysis must be run beforehand (to deliver the analysis state that is to be updated), and a full reanalysis must be run afterwards (to verify the correctness of the analysis). Therefore, adding persistent storage of analyses will lead to a major improvement in the debug and test cycle, and can be useful for benchmarking as well.
Analyses can possibly be stored using the .json format.
The text was updated successfully, but these errors were encountered: