Rhino Script Compiler for Rhino5, second Beta

Rhino Developer
142

Yep; the new compiler has an embedded version of RhinoCommon from V6 SR0 that is used for the compilation process. This means you don’t even need Rhino installed on the same computer that you run the compiler on. If you need to set a minimal Rhino version for your plug-in to work because of some feature we have added of some bug we have fixed, we’ll need to add some feature to the plug-in to inform the user that they need a newer version of Rhino.

Ok, I’m still trying to figure out the best way to deal with extra files. Still pondering…

rvb is a different beast. I can probably get in-memory python modules to eventually work instead of writing to a temp directory, but it won’t happen right away as it is “hard” and I’ve got a billion other projects to complete. I haven’t even gotten the library support working yet… :slight_smile:

I don’t know how interesting this is to you, but one of the reasons for the script compiler reboot is to support grasshopper definitions as commands. At least my monotone voice can put you to sleep in just 10 minutes.

3 Likes
143

But does a compiled script then still work if i use eg. a RhinoCommon function which was added after eg. SR20 ?

Maybe i should explain what i initially had in mind. I thought i could “connect” some files (pdf, chm, rui) using the compiler dialog which are then automatically put into the resulting rhi file. Those references whould be stored (with their paths) in the rhc file. When i re-compile, eg. if the scripts, help files or toolbars have been changed, i could skip the rename to zip part and everything is pulled automatically from the paths…

That would be best, especially to avoid problems when debugging (with variable function scope vs. module scope). It would also prevent problems when modules need refresh during runtime.

It is very interesting and i look forward to use GH defs in my scripts too. Btw. I can only see a large blank space after your text above yet. Did you fall asleep ?

_
c.

144

Rhino in general doesn’t have the capabilities to figure this out. I think we’ll need to add some minimum Rhino version setting to the compiler. The plug-in can the just say “hey, get up to date with at least x.x version” when loading and then refuse to run.

1 Like
145

+1 for setting a minimum and maximum Rhino version within the compiler. Btw. The GH features shown in the video looks very promising yet :slight_smile:

_
c.

146

Hi Steve, maybe it would be enough to add a seperate section in the rhc xml structure like this:

<embedded_files>
    <file source="E:\SomeFolder\HelpDoc.pdf" destination="\documentation\"/>
    <file source="E:\SomeFolder\Toolbar.rui" destination = "\"/>
</embedded_files>

and provide something in the compiler interface to choose those files. If the rhc remembers the source path (and maybe allows to define a relative destination path when those files are installed) this would be enough to skip the rhi to zip renaming.

btw. have you thought about the ability to include a licensing related feature like password protection for the installer file ? I guess @Jarek would benefit from this too.

_
c.

147

Including the files with the distribution isn’t hard. I need to figure out a way to let your script know where the directory your plug-in is executing to so you can access these files from the scripts.

The rhc project file now favors relative paths instead of absolute paths. You should be able to place all of your scripts and resources in the same directory as the rhc project file.

I can add functionality to the plug-in to run custom code of yours when the plug-in first loads and have the plug-in refuse to load if your script determines the plug-in shouldn’t load. Would that be enough for your needs?

148

Up to now i have written a simple script to eg. open the helpdoc. This script is then compiled and results in a command i can use in the toolbar. To locate the helpdoc, i simple find the plugin by name, then get the folder using plugin.Assembly.Location. If the helpdoc is placed in the same folder as the rhp after install, this works reliably to locate it. Finding out if a command is run from a script or a compiled plugin is something i never solved. So the plugin needs to be installed to test the (uncompiled) script.

Could you still support static (full) paths ? Reason is that helpdocs, documentation, workspace and eg. sample files are spread into mutliple locations.

Yes, that goes even farer. I thought of a simple password entry which is asked by the installer. If rhi is a zip file, maybe you could just use the protection zip files offer.

_
c.

149

Hi @stevebaer and @clement,

Great to see the compiler is finally getting an update. Looking at your discussion I can only second all of Clement’s feedback as we are doing it currently in quite similar way, running into similar limitations and needs. Steve - allowing transparent commands will be great - is that going to be a switch per-command (like Hidden for example currently) or a default state for each compiled version? First would be better.

I also use RHI same way Clement describes - adding rhp and bunch of files (html, images, etc), zip and rename to RHI to create the package. Never used Yak - if this is better option that you would recommend and achievable to use by non-hardcore programmers definitely will need to look into it. If it has a way to keep the plugins better organized or automatic update downloads that would be great.

Telling compiler which Rhino version it should install the plugin for will be great, and also maybe adding the SR detection (now we can do it from the code but will be cleaner from the compiler).

As for password-protection - just that would not really cut it for my use, as nothing stops potential user that gets the password to share it freely with anyone else, so that would not be anything I would use.
That itself is probably worth a separate topic or non-public conversation, but unless McNeel could come up with a system that allows for easy protection, licensing and distribution of scripts (kind of like Apple Store apps) that would make it secure and straight-forward for scripters to share and sell their tools, it is quite challenging to do it in a convenient way currently. Since Rhino 6 and online zoo licensing change, we lost the ability to tie the script license to Rhino copy, as the Rhino Serial Number can no longer be easily obtained via script as the method returns random key in case online zoo is used, which most users do these days. So the choice now is to tie the license to hardware, which is not that convenient if the user want to use it with the same copy of Rhino on multiple machines. So I would need a scripted way to identify the user by some unique user ID that would replace the lost ability to do so by Rhino Serial Number. I have been discussing this with @aj1 in the past but to my knowledge this never got exposed. So I vote “no” or redundant for just rhp password protection, but why not if others find it useful.

Another somewhat related limitation that I tie into this conversation is the (bug?) pertaining to running python scripts inside Rhino commands. They work fine inside commands if compiled into a plugin, which is ultimately the goal, but, unlike RhinoScripts they will not from a button, which is a good way of testing them and not having to compile each time. I have reported it before and its here: https://mcneel.myjetbrains.com/youtrack/issue/RH-56354 but slated for Future… If this could be fixed it would certainly help with my development process and testing.

Lastly, I can certainly relate to this one Steve… :wink:

Wishing you both health and a good mix of productivity and taking it easy, whatever it means…

–jarek

2 Likes
150

It is a compiler setting per command that you can change

Nothing will really change here as that would require changes to the rhino installer engine. We can add initialization code to let you decide with a script if the plug-in should load or not. Yak does allow for specifying the version that the plug-in can be installed for

I’m not going to add password protection. I can add the ability to run a script when a plug-in is first loaded and that custom script can make a decision if the plug-in should load, but that script is the responsibility of the plug-in author.

I’ll take a look at this, no promises :slight_smile:

1 Like
151

The latest Rhino WIP now includes the updated script compiler. The executable is in the same directory as Rhino.exe and can be run without the need for Rhino to be installed. You can also access it from the Tools menu in Rhino.

1 Like
152

Hi @stevebaer - are there any instructions for its use somewhere? Thx, --Mitch

153

Hey Mitch - did you watch the video that Steve posted further up?

From about 2:30 to about 5:45, he demonstrates how the updated script compiler works.
(Note: That was 5 days ago and I hear that, by now, you should be able to also use the yak file to push your plug-in out into the world)
HTH,
-wim

154

OK, thanks, I missed that one. There should be a stand-alone video and some written documentation for the compiler made available on the developer pages perhaps…

155

Hi @stevebaer and @wim,

i would like to suggest a seperate thread and preferably a direct link to the new compiler for this new version so we can report bugs, issuses and wishes. This would make it easer for Rhino 6 users to try it without installing the WIP.
_
c.

3 Likes
156

Agreed; I added this to my todo list
https://mcneel.myjetbrains.com/youtrack/issue/RH-58166

157

Hi @stevebaer, at least it would be good to know what has changed/has been added compared to the old version. Doesn’t look like adding custom files (images, docs) has been implemented, right?
Also, I did not try the “Transparent” option for command type… but it is possible to have Hidden command to be Transparent at the same time?
Agree with @clement - maybe compiler could be a separate topic category or at least topic. This is an important feature and we are @ 155th post in this thread.

thanks,

–jarek

1 Like
158

I would also like to know the following concerning updating a compiled plug-in:

Say I create a plug-in containing around 100 scripts/commands. Periodically I need to update or fix bugs in a couple of the scripts. Is it as simple as simply fixing what needs to be in the scripts, leaving them with the same name/directory and then just asking the compiler to recompile everything? Or do I have to start from scratch (hopefully not)…?

Also, I assume complied plugins work for both Mac/Windows ?

159

Hi Mtch, my answers are related to the “old” compiler of this topic title:

You can save your plugin project as an rhc file. If you need to recompile the PlugIn, open the rhc file with the compiler and build again.

No, plugins compiled with the old compiler worked with windows only.
_
c.

160

Ahh, that’s too bad, I really wanted to be able to distribute on both platforms… :disappointed:

161

Yes, the plug-ins will work cross platform.

1 Like