Rhino Script Compiler for Rhino5, first Beta


(David Rutten) #1

Dear All,

the first Beta of the Rhino Script Compiler is now available for download. It should generate RHP files compatible with Rhino5 (and hopefully beyond) from RhinoScript and RhinoPython files. Multi-file python scripts are not (yet) supported.

If you run the application by double-clicking it in Windows Explorer you can create new compiler projects, open existing projects, modify projects, save projects and compile projects. Compiler projects are pure XML files with the extension *.RHC. If you drag+drop an existing RHC file onto the application in Windows Explorer the project is compiled immediately.

This is just the first release but of course all suggestions and bug-reports are welcome.


David Rutten
david@mcneel.com
Tirol, Austria


Best Practice for Distributing Python-based plugins
Rhino Installer Engine - Creating an Installer
#2

Thanks David
Ciao Vittorio


#3

Awesome!! I will give it a try in the morning.

Thanks David,

Dan


#4

Hi David
First an second RHP files OK:
Ciao Vittorio

ViteBrugola2Orient.rhp(28.5 KB) primo.rhp(13 KB)


(Pascal Golay) #5

David, while the command window is open, I often cannot interact at all with open Explorer windows. (w7, 64 bit). I type S or Q and it gives me control back. I cannot tell if there is an open window somewhere behind the Explorer windows (Like one for locating the output folder or command file) but it looks like not. I notice that having one of these open does not prevent another one from opening if I type in the letter that calls it up, so it is possible that I’ve had two open, one hiding.

-Pascal


#6

David - this is great news. Thank you for making it happen.

So far so good - the large script files that have been failing to work under V5 64-bit encrypted with the previous compiler work just fine.

Are all the compiled plugins encrypted by default? The old monkey compiler had this as an option… just curious-I have no problem if this is the case.

~jarek


#7

Thank you David ! I´m yodeling with joy :wink:

…one minor thing though, if i open it using double click, then close it using Q right away, i´m getting a System.NullReferenceExeption. Name of the event is CLR20r3.

Could you please state a few words about the grade of encryption ?

c.


#8

Compiled 230 Rhinoscripts without any problem. The DOS window is a bit cumbersome compared to the old Monkey compiler, but I’m guessing the fancy UI will come once the technology is proven. (I hope).

Dan


(David Rutten) #9

Yeah I decided to separate the compiler from the UI. This way the compiler can be automated easily via a build process.


David Rutten
david@mcneel.com
Tirol, Austria


(David Rutten) #10

Hi Jarek,

proper encryption is not possible in any case as the scripts need to be unpacked by the plugin without the need to enter a password. But yes, the strings are no longer part of the source code and they are all encrypted. But please note that any .NET programmer worth their salt can extract the code if they want to.


Rhino Script Compiler for Rhino5, second Beta
(David Rutten) #11

Hi Clement,

yup, I’ll fix that.

Regarding encryption, it is better than the previous compiler but still relatively easy to extract. As long as the decryption has to work without the use of a password then it simply cannot be made more secure. All strings are encrypted using Rijndael 128-bit keys and they are no longer stored in the source.

If you want better protection then you’ll have to obfuscate the resulting RHPs.


David Rutten
david@mcneel.com
Tirol, Austria


#12

ok, thanks ! I guess this happens automatically if i use a black background. :wink:

c.


#13

Hi David,

I guess it was the same case in old Monkey compiler. This is still an OK-level of protection. I remember a while ago on the old Dev NG you said that anyone good enough to extract the code is not interested in stealing it; so let’s stick with that!

~jarek


(David Rutten) #14

Well, that was possibly a bit glib. Obviously there can be data worth stealing in VBScripts, but apart from the logical impossibility that we cannot provide proper encryption if the assembly has to be able to decrypt on it’s own, we also don’t really want the responsibility. So we’ll encrypt to the best of our ability while making sure everyone understands that it’s not an actual protection against theft.


How to encrypt my code?
#15

I noticed that plug-ins created with this beta version load on demand, whereas the old Monkey compiler allowed you to load at start-up. Is that something that can be added to the new compiler? Or is it there and I missed it?

Thanks,

Dan


(David Rutten) #16

Hi Dan,

what benefits from LoadAtStartUp are you looking to gain?


#17

Hmmm…Good question. I suppose the difference in behaviour is what caught my attention. Whether it has any benefit, I suppose I need to think about that. I’ve always relied on the message with date and version number that I added to see if people are running the latest version, and that was available by starting Rhino and looking at the command prompt. Now I just have to invoke a command, then I see that. Not a show stopper, that’s for sure.

I did notice that the old plug-in created with the Monkey compiler in V4 (but run in V5) is still present in the plug-in manager. I have duplicate plug-ins, and the load at start-up from V4 actually overrides the behaviour of the new plug-in. What doesn’t make sense is that the old plug-in isn’t loaded. I’ll attach a screen grab to clarify this.

Dan


(David Rutten) #18

Interesting collision. I think Rhino only cares about plugin GUID and not the names. So if you have two plugins with the same name but with different IDs then they can both co-exist. The problem then arrives when they both try to register commands with the same names.

I do not understand why the old load-at-startup plugin would cause the new load-on-demand plugin to load instead, it could be a problem with identically named commands. Either way, you’ll have to get rid of the older version to avoid conflicts. Is this something that you’d like to see automated in Rhino?


David Rutten
david@mcneel.com
Tirol, Austria


#19

I think automating this might be necessary since there isn’t a straightforward way of deleting a plug-in in a scenario like this. (Unless something has changed that I’m not aware of). Generally I’ve deleted the plug-in where it resides in my hard-drive, then restarted Rhino to get rid of an unwanted plug-in. In this case, I try that, and I can successfully delete both plug-ins. Then when I copy it back into my HD, restart Rhino, both versions are back again automatically.

Dan


(Steve Baer) #20

I would really like to keep away from “LoadAtStartUp” plug-ins if at all possible. That feature causes an increase in start time for Rhino. If LoadAtStartUp is needed, I would like to understand why so I can think about making whatever the needed feature is work without loading the plug-in at start up.