I dealt with a nasty bug last night - I’d like to report or find an explanation for.
Probably wasting my/your time.
I’m working on this project.
I’m using Rhino 8.
I was working on it using one computer, saved it. All great.
I threw it on a memory stick to open it on another computer.
Same exact Rhino 8 SR.
Data gets f^%$@p up.
Object order, so meticulously sorted and kept a certain way, changes. Components working 100% fine go ‘red’.
Wires that were solid go dashed, and vice versa.
Aborted the mission, went back to computer 1, things looking normal.
Next morning (today), opened it again on computer 2, things are as they should.
Simply…Why!!! Why freak someone out like that?
For real.
I guess the real questions are: how do I avoid this in the future? What file management skill do I need to learn? It’s only fair to inquire upon simply venting. Jokes aside, what file can I provide? The conundrum was that if I internalize data from the file open on computer 1, save a file, then do the same on computer 2…what errors can you look for if each file would now come in with ‘different’ data structures internalized? How would you compare? Are we just subject to whatever fate here?
Why would a grasshopper file open on WIP GH behave differently if no new components are added nor new changes are made? Having to relegate ourselves to R7 sometimes is kind of sad and inconvenient.
I feel fortunate than upon saving the file again on computer 1, with no new changes, then reopening next day on both computers again, the bug was ‘gone’. But, what ‘temporary’ state causes this?
Had the data stayed mangled my work team would have been SEVERELY affected and delayed in their workflow. I can admit my own human errors without a problem, but this one remaining mysterious is unacceptable, don’t you think?
I think we are lacking a couple of information. GH itself should be deterministic and I personally newer encountered this behaviour. Of course if such a rare problems occur, it is very hard to debug.
Anyway, what I wanted to contribute instead is that you are obviously not practicing any from version controlling. Any form of work I do, I usually version control from beginning on. It is good practice to at least commit work on a daily basis. With a decent version control system and enough self-discipline you can revert changes quickly. It also takes mental load from you in the end, because there is no need to worry about persistence anymore.
On top of that, if you implement a form of a self-test, you can always validate that your are not altered your work by accident. Now in RH/GH this point is hard to apply. But usually if I commit my work, it automatically runs tests in the background informing me about any problems via Teams or Mail. This is usually done by creating a Continuous Integration (CI) pipeline. This can be quite an effort to setup, but once you done it, you can really benefit from this. I wrote it a bit abstract, not naming any concrete tools, because there is no golden way for the Rhino ecosystem yet. But at least there are nowadays many possibilities to get this form of assistance.
No sorry, I was missing to mention an important information after reading this again. I‘m not saying its your fault, but you cannot rule out that you might did something odd in between.
There could be a couple of things you might accidentally did without noticing. If you version control, you get the exact copy of what you have checked in, without having the pain of using usb-sticks etc.
And if you modified it you see a diff instantly. This lowers the probability that you are comparing apples with oranges. I saw in your post history that you had issues with autosaving last week, and somehow I saw a connection to this topic. In any case non-deterministic behavior can be caused by various problems, such as concurrent computation, localization problems (sorting in differ order), fancy 3rd party code, malicious behavior etc…
But if you know that whats on your side is exactly the same as on the other machine, you know your manual intervention did not cause the problem, and this is a valuable information. Its really hard to investigate problems if you likely did 10 unmentioned steps in between. Did you copy the exact file? did you delete an object shortly after loading the file? (…)
Apologies for being both facetious and bad at explaining
Understood, however that wasn’t the case. If copying it to an external SSD counts as an unmentioned step, then sure…rhino SRs were still the same, just different computers, both windows, if that matters.
I literally worked on a file, copied it to an external drive, brought it back. Always saved.
Detailed summary:
I worked on original file using computer 1. Saved it.
I copied the file to an external SSD and worked off of it on computer 2. Saved it.
I brought back the SSD and opened the file on computer 1 again:
malicious mysterious bug manifested
(decided not to save and closed it, opened it again, bug persisted, didn’t save and closed it again)
I freaked out, said “nevermind” and went back to computer 2 - file was fine again - kept working off the SSD. Saved it.
Next day, I opened the file on both computers 1 and 2; it was fine.
I gave up on uploading anything - the file is HUGE - no plugins, but internalizing data from both computers where things were now ‘normal’ again seemed rather pointless. Not sure how to replicate the issue.
I guess a better example I can fish is in other grasshopper files where operations are behaving differently on WIP versus R8 versus R7 even if no new changes are made.
Version controlling means to use a 3rd party application which stores your project folder inside a database. This folder is then monitored by that application, and as soon as you change a file, you are out of sync and basically creating a new version of your project.
Whenever you check-in a change into this database, you get a new version of your project. These apps are usually smart enough to only store the diff and can therefore always show you which file has changed. Text-based files are even diffed by its content. So you see the difference in the text.
The big advantage is that you can dismiss these changes or go back and forth in history without losing your work.
Ideally this db is hosted in the cloud, or stored on a local server, or a least on a drive other PC‘s have access to. Because of this you can checkout the project version on multiple PC‘s without the need to manually exchange the data. This eliminates sources for error and ensures everyone works on the same version. It also improves collaboration, because you can merge data from different users etc. You further automate tedious works of manually saving your file. But dealing with covariants is another topic and differs by the system you choose.
Examples of such apps are Git, SVN, Mercurial, Starteam, Windchill etc.
They work very different, but all of them have in common that they solve the same problem in a very generic way. It doesn’t matter if its a .3dm file or .jpg. So all of them are suited for your work.
There is one difference to note. Git is state-of-the art, but it is designed for software developers using text files. There is something like git lfs to store larger binary files. But in general, for CAD work any of the others might work better. Git is also a bit harder to get into it, but is the most modern and most powerful system to choose.
I just want to mention, that I very often notice accidents by having a look into my git diff. So its a great way in ruling out own error.
Hope this was simple enough, just watch some videos and you get a better idea…
I finally managed to catch/replicate this bug again.
'Feeling equally hopeless because you’re going to want a file, but can’t share it.
So I just want to demonstrate.
I have the same file opened twice. One is stored in my computer (original location) and one is in an external SSD. Both are the exact same file in terms of their content.
See video:
Beyond inconvenient…perplexing, scary.
Great appreciated tips from @TomTom, but really? Does one need to exercise some crazy control method to keep this from happening?
The file in question was worked on using the computer, then copied to the SSD, then copied back.
No of course not. As I said it will just rule out certain types of user errors. But if both files are the same, then it’s certainly something in the definition or in Rhino/GH itself.
I mean its strange that it does not compute deterministic. If this is the case then very often its based on concurrent computation. And of course there is a certain latency if you load data from an external drive. How do you import your data in you GH script? You mentioned that the order is messed up. Are you using a native component, a plugin component, or are you de-serialising from a custom script? If last, are you loading asynchronously?
this will sound very stupid… but overlapping the two different screenshots of the whole definition results in a PIXEL PERFECT correspondence everywhere but in 3 locations
the first and the second different areas are your zoom-ins with red components, so you are already fully aware of those
might of course mean nothing at all, but it looks like a few components in that area on the second file are horizontally longer than the very same from the first file
my brain recalls weird things happening when I open random gh files from the forum, as if those files inherit the “full name” or “draw icon” settings regardless of my own settings, but the only case where that might be an issue would be if you are using expressions… those components in your file are not red, so that is not the case, but for sure they appear horizontally larger on the second file, please have a look
Tom,
I wish I were smart enough to answer your questions.
I just make this thing, man…save it, move on.
SOMETIMES I must work away from the office, so I throw my GH file in a flashdrive, or SSD, or email it to myself, whichever is less of a hassle.
by the way:
there’s only one plugin in use, which is OpenNest, for text outlines…BUT: I’m using one component only at the end of the algorithm…that’s later in the script, after the nasty bug has already manifested. I can delete that single component and the errors would prevail.
Anyway, let’s make this bug manifest (again) in the silliest way possible. See below.
First, I have the file open from the SSD, running 100% fine. Just for fun I ‘save as’ again, and put it in the same SSD with a different name:
Then, I open that new file, still in the SSD, running 100% fine:
Watch what happens if I simply copy that file to my computer:
Last time the bug manifested going from one PC to another, both with same R8 SR, but now I’m on the same machine. At least now I know the multiple computer scenario isn’t the culprit. Must be the SSD, my ignorance, plus all the things Tom mentions…but definitely not Rhino
Thanks Clark.
I understand. Some times you have the time to organize, other times you don’t, you’re in production building a giant prototype in the shop, outputting parts. The order is in your head. I don’t need the script to be pretty for it to work fine, especially if I’m under the gun.
Thanks again
P.S.:
Right…we agree on something
Ding! That’s why I say it’s a malicious mysterious bug! What could be the error from copying and pasting? LoL. Just see the videos above.
Trust me. Worked in two productions environments and I really learned how important organization is when it comes to weird acts of god incidents like these haha.
