Hops 0.6.1 now available via the Rhino package manager
What’s New
Asynchronous solving
Each Hops component has an option to solve asynchronously. The user interface will not be blocked while waiting for a remote process to solve and the definition will be updated when the solve is complete.
Async solving is controlled by toggling the feature on the component’s context menu
Path and Enabled inputs
The context menu contains items for toggling path and enabled inputs.
Maximum concurrent requests setting in preferences added. Asynchronous solving can end up with a large number of requests to solve which ended up causing request timeouts. Hops now has a request queue to handle this potential large number of requests and a set limit of the maximum number of concurrent requests to be happening at any given time
The hops component attempts to detect when inputs and outputs have changed on a server and will rebuild itself
ghhops-server has also been updated on pypi to attempt to help with the above situation where the server changes inputs/outputs
How does Hops handle the order of the response from the async calls? For instance, what happens if the first solve takes longer to compute and is returned subsequent to the response for the second call? Is there a risk that you will end up with outputs that don’t match with the current inputs?
I use a rolling serial number to attempt to make sure the data set that was solved matches the current inputs. If an asynchronous solve completes with an older serial number, it’s values are still cached but they aren’t used.
Please double check my work though if you get a chance. You can see the logic for this in BeforeSolveInstance and SolveInstance in the HopsComponent class.
We could eventually apply this logic to all TaskCapable components if we find this works well with Hops
