Closed Christian-B closed 2 years ago
Christian-B
commented
2 years ago We could probably use the Freeze also to block edits to either the original application or original machine graph once one is changed replacing the current safety code.
Not done as the machine graph may disappear.
Christian-B
commented
2 years ago Lets see where the view and reduce overhead stuff goes first.
Christian-B
commented
2 years ago HOLD!. Only needed if reduce_overhead branch when finished still needs the two Application graphs.
Christian-B
commented
2 years ago No longer needed
Must be done at the same time as: https://github.com/SpiNNakerManchester/SpiNNFrontEndCommon/pull/900
tested by: https://github.com/SpiNNakerManchester/IntegrationTests/pull/88
This moves the track of graph changes and freezing into the graph itself.
In the past ASB had a flag_vertices_or_edges_added This works fine if the update passes through ASB but fails if does not.
Global data will make it even easier to access the graphs so more likely a change will happen behind ASB/GlobalData's back
Now the graph tracks when it was last changed and on what change a clone was created. By comparing an original graph to the clone it is easy to see if updated now matter how. If there is no other graph it the graph is considered update since cloned
In the past when we passed graphs in a way users could access we build a View/Clone with add methods disabled.
In this pr this is changed to the ability to freeze the graph. Freezing the graph will happened after partitioning and inserting the monitors, gathers and their edges
There is no need to unfreeze a graph as if the graph needs changing a new clone should be created.
original graphs are never frozen as if passed to the user (typically GFE) the user may add to them. (which make above change critical) In the past they where not passed as views.