Please excuse me if this is not the correct topic for this section.
When during trial & error process in grasshopper with ghpython component, user creates an infinite loop by accident, grasshopper, respectively rhino crash.
This leads to loss of unsaved stuff, that even the recovered file is not saving. Not to mention it ruins the experience and one starts to wonder how reliable GH is for prototyping.
There should probably be an exception displayed that there is an infinite loop instead of trying to run it and end up crashing Rhino.
The “while loop” in particular, every time I try to use it I crash Rhino. This restricts me to look for alternative methods like “for i in range(a,b)” but this doesn’t work in all cases.
I know a little programming different languages different syntax in my head but I’m not a programmer and it happens frequently to just try different stuff with python and see what works. Leading to a lot of errors and unintentional loops.
I don’t know about Python, but I can assume it have statements to handle exceptions. Look for “Python infinite loop break” or “python try catch”. The machines are stupid, you have to specify everything.
And by the way, I developed an naive plugin to automatically save the new documents (making the auto save always active).
I agree machines are stupid but trial&error is part of the process of innovation and prototyping and such crashes should not happen.
Last time I used while loop I also used a break but nevertheless rhino crashed. If I wanted to go deeper in programming I wouldn’t have been using grasshopper now, woudln’t I?
If your infinite loop creates infinite objects, there is no way for Grasshopper to save it. Also, generally, you’ll have to think about some way to prevent the loop to go infinite ahead of time.
Yeah, from what I understand this is a limitation of Grasshopper being single-threaded, and GH2 (when it comes out) will allow you to interrupt solutions while they are ongoing.
I would approach while loops or anything that could potentially run infinitely with caution (this applies very much to programming outside of GH too).
In Python one easy way to prevent this is replacing
while condition:
do_stuff()
with this:
for _ in range(1000):
if condition: break
do_stuff()
else: # optional
raise Exception("ran out of loops")
which is guaranteed to terminate after 1000 or however many loops you choose.
The issue is not so much about saving as much as it is about the crash. There should not be a crash, there should be an error message just like syntax errors are shown.
Crash means it’s an issue in GH.python.engine not in my code.
That’s not something up to the language these days. It’s something up to the developer
Also, it might be very very difficult to devise a language that can always predict the amount of repetitions of a loop. But that’s not really a concern of avant-garde language developers as far as I know.
If you are really scared of goofing up, then just make sure that a call to scriptcontext.escape_test(False) is always within the most-nested loop.
I’ve never been able to get scriptcontext.escape_test to detect the escape key in Grasshopper, always assumed that it only works when called from Rhino.
Even when exploring in a trial-and-error setting, you’ll generally have a rough ballpark idea of how many iterations or how long the script should take to run - besides it’s easy enough to detect if the for loop has run to completion and then increase the upper bound.
import time
start_time = time.time()
while condition:
do_stuff()
if time.time() - start_time > 60: # 1 minute limit
raise Exception("time's up!")
PS. There’s no way any programming language or runtime can detect whether your script will eventually halt or continue running to infinity, and raise an error message as you suggested - one of the fundamental theorems of computer science tells us that this is impossible: Halting problem - Wikipedia
Well, from my point of view, the responsibility belongs to the user of the tool, not to the tool. There’s a way to use it correctly, a thousand ways to misuse it. If you break a hammer hitting a nail, it’s the hammer’s fault, if you break it hitting, I don’t know, lava, it’s the person’s fault.
This is a typical developer towards customer type of talk in the last years.
When all applications were written in c/c++ or asm in the past all applications were optimized and devs were obligated to assure their applications won’t fail.
Today all applications even released as final build are in fact alpha/beta builds. And the whole lifecycle of a release is used for beta testing. Also something cruicial, nowadays customers are treated as QA and beta testers even though they pay for the software. And programmers are becoming lazy and dumb. No offense I’m not saying this for McNeel as even if I am a Rhino user for many years as a designer for different companies, just resently became owner of a license. I’m generally talking about DS and MS.
Now on the hammer analogy: if the hammer’s sole purpose is to withstand hitting with it, hitting a nail or a wall should not matter. If it breaks using it for hitting then the issue is not how the customer uses it. It’s the manufacturer. If you use the hammer to derail a train and the handle breaks, that is a classic case of a misuse and it’s the customer who should be blamed.
Grasshopper’s purpose is introducing parametric design in Rhinoceros as well as prototyping (in fact mostly prototyping). That makes prototyping, trial & error GH purpose. Devs should provide GH stability of the software even if the code of the customer fails. Means to do that is using error messages and exceptions, and not by allowing rhino to crash.
Internet is also full of junk and obsolete information, much of what I read about python and ironpython is either wrong/old or reletated to libraries not accessible from ghpython.
That’s why I ask for explanation here.
Btw, even grasshopper3d website is filled with stuff that no longer work and deadlinks.
For general “what is X syntax” questions (in the future) you really can’t go wrong with Google + stack overflow… the first search results for both your questions was high quality and much more in-depth than you could expect from these forums.
But back on topic somewhat - @piac the attached script with sc.escape_test()did not work for me, both on the latest GH for Mac and on Windows where I’m still stuck on Rhino 5:
Looks like the Escape key is caught by the GH canvas only after the python component is done with all 10000000 loops… good to know that it works on Rhino 6 though
Software licenses are not guaranteed for any purpose, but are often offered “as is”. You’re not paying for what you want to buy, you’re paying for what’s sold. It’s simply unattainable to handle all possible user errors. The best option is to treat the user in these forums. I agree that it’s okay to demand a more stable product and I’m convinced that no developer wants to do things wrong, the point I’m making here is that there seems to be a strong misunderstanding with the nature of software because that’s where the expectations come from. If you want to understand it, you should consider it more like an organism, like a garden, rather than a black box of inputs and outputs.
yes I know, but you provoked me to ask.