Python Installation Error

Replies to This Discussion

Permalink Reply by David Rutten on April 16, 2014 at 2:43pm

Guids (Globally Unique IDentifiers) are 128-bit codes that are often use to identify items in a collection. For example every Rhino object in a 3DM file has its own Guid, which allows programmers to easily 'find' the same object again and again. A Guid looks like this: 

cff6eee0-e43e-4a5d-ba62-e1ceda0df389

though of course every Guid has different letters and digits. We (McNeel) provided a template for Grasshopper plugin developers and this template had a mistake in it which caused an invalid string of characters to be used as a Guid. This causes an error during runtime. We've fixed the templates, but old plugins may still have incorrect guid strings in them, only the developers in question can fix that.

The error message you're seeing is because a plugin has crashed at a point where the most likely explanation is one of those faulty guids.

What is weird is that the plugin is one of our own, which should never have had this problem in the first place and even if it did, should have been fixed by now. I'm wondering if we're mistaken about the reason for the crash. I think Giulio is better equipped to handle this, he's the author of the Python plugin as well as the VS templates and he found and fixed the original bug a few months ago.

In the meantime, if python works correctly, just ignore this message. Apologies for the pointless extra mouse clicks in your immediate future.

--

David Rutten

david@mcneel.com

Permalink Reply by Giulio Piacentino on April 17, 2014 at 12:32am

Hi Tristan,

more easily explained, you probably ran an old version of the wizard on your machine that used the old Vb.Net template edited by David.

It should be relatively easy to find its .gha file. I have no real understanding why the title of the error is "Python interpreter loading problem". I think this is just a typo. This has nothing to do with Python.

David, by the way, if you get around to it, please fix this title in the message box.

Thanks,

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by David Rutten on April 17, 2014 at 4:03am

The string "python" does not occur anywhere in GH source except twice in comments.

The title text of that message box comes from the name of the assembly itself.

--

David Rutten

david@mcneel.com

Permalink Reply by Giulio Piacentino on April 18, 2014 at 1:15am

Ok, interesting. Then it must be something else. Tristan, did you compile GhPython yourself? If not, which version is it?

I am really just having a hard time figuring out why this error can happen it the Assembly.Id property.

GhPtyhon does not override that property at all. So it might be the default implementation that throws an exception.

What I can do, is making sure that future versions come with the assembly Guid set.

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Tristan Wolfe on April 18, 2014 at 7:03am

No, I just loaded 0.6.0.3. The last time I had a weird Grasshopper issue it was because of the security on my machine. (The joys of working for the DoD.) Just throwing out ideas.

Permalink Reply by Giulio Piacentino on April 18, 2014 at 3:12pm

Now that you mention this, I'm pretty sure this is a problem with loading the hashing algorithm implementation that Grasshopper is currently using, which might be restricted.

We are probably able to fix this both in Grasshopper and GhPython. For now, does hitting "OK" fix the problem for the current session?

Thanks,

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by David Rutten on April 18, 2014 at 3:45pm

I fixed the MD5 hashing problem in the latest release. If you haven't updated to the current version then please do so now to see if the problem goes away.

--

David Rutten

david@mcneel.com

Permalink Reply by Tristan Wolfe on April 22, 2014 at 5:26am

If you'll recall, I was the reason why you fixed the MD5 hashing problem in the first place. I'm running the most recent release. Does it try to load the python module (sorry, I don't know the correct terminology) before it does the check and switch to SHA?

 

Again, throwing out random ideas here.

Permalink Reply by David Rutten on April 22, 2014 at 7:43am

I just realized that code has always used SHA256Managed, which is probably also not acceptable. Only the unmanaged SHA implementations are FIPS compliant.

Sigh...

--

David Rutten

david@mcneel.com