Rework serialization of parameter sweep configuration#15
Merged
Conversation
Weirdness in the analysis.
All deserialized models have listeners that need to be initialized and registered to the main ParameterSweepModel. But when deserializing Gson, the constructor of the base class is not called, and the listeners are not re-registered. We try to work around this in a better way: - The listeners field is initialized in the class definition, not in the constructor. But this does not work all the time either. For a reason that completely escapes me, sometimes an instance will not have this field initialized. Weird. - A default visibility method is called by the Gson deserialization logic to re-register the listeners to the main model. - The param models have also an initialize() method that recreates the listeners. - Special case for CondaEnvParamSweepModel: the env list is cleared after deserialization and replaced by the env list discovered at runtime. - Also: all RangeType enums have been renamed according to what is their mother param type for clarity.
We may have serialized that the module was not available or properly configured at the time of serialization. In that case, the submodel is only one information parameter. Instead of returning it, we try to instantiate a new model, so that the user is presented something par with the current configuration they have.
tinevez
changed the title
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This PR introduces the following 'quality of life' improvements for the user:
When a user launch the plugin in a location that contains a
helperrunnersettings.jsonfile, it deserializes it to present the user with last used parameter sweep configuration.But sometimes users may have serialized that the module was not available or properly configured at the time of serialization. For instance if you did not install TrackMate-Trackastra, the fact that it is missing will be serialized. And it will be deserialized, even if the TrackMate-Trackastra module has become available.
Now when deserializing, we detect whether we serialized such a case, and if yes, we try to re-discover the module.
We now have a special parameter for conda environments. The list of conda environments available is still serialized, but it is ignored when deserializing, and replaced with the list of actual conda environments present at runtime.
The serialization logic is still complicated. I could not find a good way to simplify it keeping everything we want for the user.
I tried to at least clarify it a bit, and use non-conflicting class names.