simulator: implement --load flag
#720
Draft
+152
−110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- makes interaction plans serializable - fixes the shadowing bug where non-created tables were assumed to be created in the shadow tables map - makes small changes to make clippy happy - reorganizes simulation running flow to remove unnecessary plan regenerations while shrinking and double checking
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current status of the PR is halfway. The new framing of simulation runner where
setup_simulationis separated fromrun_simulationallows for injecting custom plans easily. The PR is currently missing the functionality to update theSimulatorEnvad hoc from the plan, as the environment tables were typically created during the planning phase.The next steps will be to implement a function
fn mk_env(InteractionPlan, SimulatorEnv) -> SimulatorEnv, add--loadflag to the CLI for loading a serialized plan file, making a corresponding environment and running the simulation.We can optionally combine this with a
--saveoption, in which we keep a seed-vault as part of limbo simulator, corresponding each seed with its generated plan and save the time to regenerate existing seeds by just loading them into memory. I am curious to hear thoughts on this? Would the maintainers be open to adding such a seed-vault? Do you think the saved time would be worth the complexity of the approach?