Rhino Script Compiler for Rhino5, first Beta

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

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

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.

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

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

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.

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

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

c.

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

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.

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

Hi Dan,

what benefits from LoadAtStartUp are you looking to gain?

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

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

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

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.

I’ve been thinking about this all day, and I couldn’t come up with any tangible reason to load at start up. My lame reason posted earlier is hardly worth delaying the start up of Rhino.

Dan

So nice! Thank you!
The first test with rhino 5 sr4,RhinoScript vbs file.
rhinotomidas.rhp(8 KB)

Hello @DavidRutten

I tried the compiler and it has worked well but I have some questions because they do not know is what exactly does the compiler.

The compiler creates a command for each file .py. If I have several files .py with the same functions, is there any way to put these functions into one file? I have the same question with the “objects” created and variables.

I have another question, can only create a single command for each file. py?

Sorry my English is bad

thanks

This is something we are trying to figure out. Currently, the compiler creates a command and associates it with a single .py file. This was done because it was the simplest way we could think of to make it work. We are open to suggestions, so if you have an idea on how to improve this for python please let us know.

Do you have an opinion on what would work best for you with respect to python?