Sometimes our Grasshopper definitions go into (Not Responding) mode, and we have to kill the Rhino process and start over. Is there’ a way to see/document back to McNeel what’s casing this crash?
thx,
G
“Sometimes” out of the blue, or “sometimes” repeatably?
Sometimes as in ‘it happens often, like a couple times an hour’ when tweaking values and not in a repeatable fashion.
But the (not responding) nature of the crash does not cr are a crashdump that I can share. Unless there’s a way that I’m missing out?
G
No, unless there’s a repeatable process or a crashdump, there’s no way for me to inspect the problem. I have not seen this myself, so it could well be that you’re doing something which triggers this that I never try. You’re absolutely certain the program is stuck, as opposed to just calculating for a long time?
My 2 cents (in case that you need that definition running at any cost).
Disable components down the tree until you cannot make it crash. Start turning them on until you find the one that triggers the crash. Enable profiler widget. Once you did that, when you leave work, leave GH after you make it crash turned on during the night. If next day it is in the same state upload the definition with the problematic component disabled so other people can test it. If when you come back grasshopper is not locked and the calculation time is just to high, you are doing a very heavy calculation or something wrong.
“Tweaking values” is too generic in the gh environment to detect where your problem could be (as David said).
BTW @DavidRutten , a widget showing the progress of the definition calculations over the canvas could help to understand this kind of issue and “debug them”. Imagine a colour map flooding the canvas at the background embracing components that have SolutionPhase.Computed. I don’t know how the canvas refreshing process is linked to the components computation, but if somehow they are independent, this could be a nice thing to have.
Cheers.
Would be a lovely thing to have, unfortunately GH1 solves the files on the UI thread, meaning that you cannot have drawing updates at the same time. Or, you can force drawing updates and pump messages, but that would severely slow down a solution and mess with it in non-standard ways, making the debugging less useful.
Mmmm…Does this mean…that sequels can do better? 
I hope so, it’s complicated stuff, but the idea is that solutions are both multi-threaded and background threaded. This means that (1) they can be more easily cancelled/superceded and (2) the UI remains live. However there’s a lot of complication that comes with this as well.
I can imagine. Let me know if ideas related to the UI detached from solutions are welcome. I think that making the canvas “alive” could be the next big thing (linked to information from other areas…)