GhPython compiled components Hints issue


#1

@piac

This tutorial was very helpful! I’ve succeeded in making one component, but unfortunately, I’ve run into a bit of a roadblock. :frowning:

I’ve tried using the first method (Compile) to create a component that has type hints ‘List Access’ and ‘Guid’. It seems that when I try to use the compiled component, my type hints are not maintained, i.e. it works when my component is just a Python script but raises an error regarding the input type when I’ve turned it into a component. So say I set the type hint as ‘Guid’, it ends up expecting ‘UInt32’ as a compiled component.

What could I possibly be overlooking in the steps? Would it be resolved if I used the second compiling method instead?


Problems loading GHPY assembly
Tutorial: creating a Grasshopper component with the Python GHPY compiler
(Giulio Piacentino) #2

Hi @Bianchi

I split the other topic into a new topic.
Do you have a small sample you could send me to test this?

Giulio

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


#3

Hi @piac

Thanks for the reply. This sample has the Python script component before compilation as well as the compiled component:

sample.gh (13.1 KB)

While this script component has large amounts of code reliant on an outside package, I did not remove them as otherwise it would be difficult to illustrate what the components are trying to do.

The issue crops up with the inputs ‘lhs’ and ‘rhs’. They are supposed to take geometry as inputs, with the type hint set to Guid with List Access. So in the scripted component this works, but this is not maintained in the compiled component.


(Giulio Piacentino) #4

Hi @Bianchi

I fixed this issue. This week’s WIP should contain the relevant commit:
https://mcneel.myjetbrains.com/youtrack/issue/RH-40117

You can also just compile the code yourself using clr.CompileModules(). You will need to change just a few lines from:

        p = Grasshopper.Kernel.Parameters.Param_GenericObject()

to

        p = Grasshopper.Kernel.Parameters.Param_Guid()

Giulio

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


#5

HI @piac,

Just an update: still encountering the same issue with the newest WIP. Is it still being tested?


(Giulio Piacentino) #6

Hi @Bianchi

I compiled your sample in Rhino WIP (6.0.17180.4221, 06/29/2017)
It seems I get the compiled Guid hints as Grasshopper-native Guid Params:

However, in the currently released WIP, 6.0.17178.4271, 06/27/2017, the fix is not yet present. This means it will be there in next week’s WIP or any WIP after the 17180 one.

You might need to use manual compilation and manually tweak the result if you need this before. Does it help?

I will be on vacation till next Thursday. I’ll make sure to check this topic again after that.

Giulio

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


#7

Thanks for the reply, I’ll tinker around with the suggestions you gave for the time being. Looking forward to the update!


#8

Hi @piac,

The newest update has solved most of my component compiling issues, but one of them appears to be causing me some trouble.

I’ve tried compiling it manually, i.e. with the clr method. For this particular component, I could not compile it with the automated method because I was getting the ‘illegal characters’ error. I was able to make a ghpy file of the component, i.e. compile the ‘main.py’ script; however, it causes Rhino WIP to crash, and whenever I try to restart Grasshopper after opening Rhino again, it continues to cause the program to crash. After deleting the component made using clr methods, Grasshopper has stopped crashing, so it appears to be the cause.

I’ve attached the files I tried to compile to make the component (called ‘shape_to_geometry’) here. I think the issue may be with the main.py file, or that I lack certain imports in the ‘shape_to_geom.py’ file.

main.py (83 Bytes)
shape_to_geom.py (10.8 KB)

Here is the compiled component, if it helps to better illustrate what’s happening.
shape_to_geom.p2.7.5.0.ghpy (51 KB)

What am I missing in my code such that it causes Grasshopper to crash when trying to import the component? Also, is there a way I can adapt the component code itself so that I can use the automated method of compiling instead? It would be good to get some feedback. Thanks!


(Giulio Piacentino) #9

Hi @Bianchi

in order to test this better, would it be possible to also have the .GH file?
I have a few suggestions based on this, but I’d like to see the Grasshopper file before going into details.

Giulio

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


#11

Hi @piac,

Here’s the gh file with the scripted components on their own.
components_to_be_compiled.gh (27.0 KB)

I assume you just need to see the code itself, not necessarily run it fully. The component in question that’s giving me trouble is the input S output G component.


(Giulio Piacentino) #12

When I attempt to load the .GHPY file, I get this exception:

How did you create it? Did you create it using the _EditPythonScript editor in Rhino WIP?

Especially, this makes it looks like the generator was a 32-bit program, and therefore this cannot be loaded in a 64-bit program such a Rhino WIP.


Problems loading GHPY assembly
#13

Yes, that’s correct, I edited the scripts using the EditPythonScript editor. Should I be creating them in an outside editor instead?


(Giulio Piacentino) #14

For some reason your code does not create a valid assembly. I am investigating.[quote=“Bianchi, post:13, topic:45219”]
Should I be creating them in an outside editor instead?
[/quote]

No this is not required and worse for troubleshooting now.


(Giulio Piacentino) #15

Hi @Bianchi

OK, so I am here reporting back from testing your setup carefully (for the part that can be tested, which is all except sortal).

  • I tried going through the automatic single-component test and it was not successful. There was a bug in the path-constructing code that was preventing it from running. This will be fixed in next week’s WIP.
  • I then used the manual “Copy compilable code” option. Please note, that you should include, in the compilation arguments, also your sortal.py module, if you want it to work on other machines.
    • I got the file that is saved as testrefpoint.py in the attachement ZIP.
    • Then there was a minor need of modification of main.py. I just changed the reference to testrefpoint.py. You also need to add sortal.py to it if you want the compiled code to actually do something!
    • After running main.py in the EditPythonScript editor, I got the shape_to_geom.p2.7.5.0.ghpy that you can find in the ZIP file. This is a valid .Net assembly and can be used by the IronPython interpreter. Grasshopper loads it immediately.

Please let me know if you have other questions regarding these steps, then we can see any additional problems.
Thanks, kind regards,

Giulio

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

Bianchi_forum.zip (20.1 KB)


#16

Sortal is a package of scripts (it’s a folder, not just a single .py script), so I’m wondering how I should include it in the compilation arguments and in which file. Where should I add in the ‘sortal’ compilation argument and in what way? I.e. Should it be included as a docstring in the script to be compiled (example in the picture) or in another form?


(Giulio Piacentino) #17

You need to add all files of the sortal package to the main.py line with clr.CompileModules(...) for compilation.

If sortal is your package (or even if it’s not, if possible) I’d suggest to simplify its structure and put all code into a single module (a single file). However, I do not think that clr.CompileModules() as restrictions per se.

You can read about clr.CompileModules, for example, on this post:


#18

Thanks for the help. At this point, I don’t think it’s best to do that with the sortal package (i.e. put it all into a single module) given that it’s thousands of files and many of them import from each other, so I’ll just tinker around with clr.CompileModules for the time being.