A new version of Hops (0.11.0) is now available via the package manager.
What’s New:
You can now export the last API request and response made from the Hops component to the compute server. There are two endpoints that are hit during any Hops routine. In the first API call, Hops sends a request to '/io' which uploads the referenced grasshopper file (along with some other settings) to the compute server. Compute processes the file and returns a response with necessary information for the Hops component to populate its inputs and outputs. The Hops component then gets the incoming values being passed into the component inputs and sends that information over to the '/solve' endpoint. Compute checks its cache to grab the right grasshopper definition and then feeds in the input values it just received into the definition. Once it gets a result it sends a response back to the Hops component which then passes that data to the appropriate output parameter. Each of these requests and responses can now be exports (as .json) so that the process can be inspected and debugged.
An API Key input was added under the Hops preferences section. The API key is a string of text that is secret to your compute server and your applications that are using the compute API e.g. b8f91f04-3782-4f1c-87ac-8682f865bf1b. It is basically how the compute server ensures that the API calls are coming from your apps only. You can enter any string that is unique and secret to you and your compute apps. Make sure to keep this in a safe place.
You may be asking why you need an API Key. Technically, you don’t if you are testing and debugging locally. The API Key string is optional. However, if you are using rhino compute in a production environment you should definitely consider using an API Key to authenticate your requests. Which leads to my next point (which is not strictly part of the Hops package, but still notable). I have just released a new document showing how to setup rhino compute in a production setting: Deployment to Production Servers with C#, VB. This new guide uses a set of powershell scripts to automate the process of installing rhino.compute and IIS on a remote server or virtual machine. This guide replaces the previous version which only deployed the compute.geometry project as a service.
What was fixed:
Logging has been cleaned up in the compute console window. Lines that are generated from the compute.geometry project are prefixed with the letters “CG”, otherwise you can assume the line was generated from the rhino.compute project. Port numbers (ie. 6001, 6002, etc.) for child processes are now also prefixed to the compute.geometry lines as soon as they are assigned so it is easier to see which child process is handling a given request. The '/healthcheck' endpoint will still respond with a “Healthy” message if your rhino compute instance is up and running, but the request will not be logged to the console per this thread.
As usual, the change log for this build can be viewed here.
Since I get no responses to my questions or my offers to assist/help, I’m asking again:
When can we expect an update to ghhops-server fixing the handling of DataTrees? I have already made a suggestion how to fix this, also in the form of an issue. A corresponding PR including examples for testing and a verification screenshot ishere
Lot’s of datatypes in params.py are still missing. When can we expect an update to that? Will it be less than in a year? A corresponding PR including examples for testing and a verification screenshot ishere
We are actively developing tools that use the ghhops-server functionality. I am aware that Hops is in a very early state but still I’m starting to get really annoyed by the fact that developers don’t seem to respond to questions/requests/offers to help. If there is too much to do, why don’t you let people in the community contribute through pull requests??
If this is all not possible for some reason whatsoever, can you please at least give a sound reason why development on ghhops-server has basically come to a halt since 12 months and when we can expect it to go on?
Sorry about that; your PR is in my email inbox and I have not found the time to review it.
Reviewing a PR fix for tree input is hard because I’m not exactly sure what is broken. I attempted to add support for this quite a while ago and need a better understanding of why my commit is not working for you
Hey Steve, thank you so much! I really appreciate it. I hope you can excuse my temper, I can assure you it’s nothing personal (quite the opposite in fact)! I know you have a lot of projects and different trajectories to take care of.
It’s more that I sometimes can’t wrap my head around why McNeel isn’t upping their staff just a teeny tinsy bit, since at least from my perspective it’s quite clear that all of you devs are always head over heels submerged in work. But then again, who am I to judge from the outside
So the quick version: THANK YOU! Hope I wasn’t too offensive.
You are right about the devs. The big problem is that they want to set their own priorities. This wastes a lot of the time they could be coding when it would be so much more efficient for them if they would just ask ME!
Don’t know where you going with this. Nothing wrong about setting their own priorities. But if you have countless projects to push further and develop, it might make sense to add a little staff to cope with the workload. In case your goal is to mock my comment - I wasn’t suggesting they’d ask me, I’m just trying to contribute to a feature I love. Isn’t that the point of open-source development? Whatever, I guess. This case is closed for me.
We have upped our staff quite a bit in the last few years. Over the same time, the number of projects have increased, training is needed for certain areas of code, developers need to be interested in the projects they work on, some devs have retired… I wish it were as easy as just grabbing more bodies, but I’ve never found that to be the case.
Your PRs have been excellent which in my experience is rare. I usually get a massive blast of code changes in PRs that are nearly impossible to understand, hard to merge and can sometimes upset the contributing author when I reject them. I’ll try to pay attention to your PRs a little closer in the future (and yes I am looking at your other PR today).
This is great to hear Yes, of course - sometimes my reasoning is probably all too simple. Of course you’re right, it doesn’t make sense to just grab bodies.
To add to this discussion… I’m one of the new hires :). I started in October and have been specifically helping on the the Hops/Rhino.Compute project. Most of my focus thus far has been on production deployment, but I have been trying to implement new features too… So your suggestions are always valued and we will do our best to get as many feature requests reviewed/implemented as we can.
Hope I wasn’t too offensive.