Rhino Script Compiler for Rhino5, second Beta

Thanks, this helps me a lot in understanding your process. I have added the ability to set version numbers to the compiler so you may be able to use that to help make decision. I’ll need to think about how to make this easy to access from a script.

I’m focusing on V6 and V7 as targets with this version of the script compiler. I can tweak things so you can still create a V5 plug-in, but at the moment the plug-ins created with the new compiler are only for V6+. I have also removed the rhi compile option in favor of always just generating an rhp and a yak distribution. I can add the rhi logic back if we find a strong need. For now you can manually create rhi files if that is your preferred method of distributing your plug-ins. @will has been thinking about ways to make it easy to host your own private yak server for maintaining internal yak packages which are a much better solution for keeping everyone up to date with the correct version. By yak, I mean the TestPackageManager command in V6 and the PackageManager command in V7.

This new compiler targets V6, so V5 won’t be able to load these plug-ins. Is that a problem that I need to work on?

I can totally understand. The current situation doesn’t really help people maintain good coding habits by having reusable functions. I think I can get this to work by unpacking modules to a temp directory, adding this temp directory to the top of the search paths and then running the script.

No, the script compiler is an independent exe that includes an embedded V6 RhinoCommon that plug-ins are compiled against. We can include this in V6 as well or ship this as an independent exe.

Getting this in the WIP is more of a convenience for me so I can keep updating the project and let everyone stay in sync.

Sounds great. If i can rely on the version number i set in the compiler (which is later the folder name which is created) that is all i need to have to build a relative path. This would also ensure that users can just overwrite an installation and all files provided with the installer.

Please make sure to keep the Compiler Option to choose the RhinoCommon.dll. I have a larger client where it often takes a long time to roll out a new SR, so i have stored all RhinoCommon.dlls for all Versions and SRs. This way i can work with the current Rhino SR and still compile with backward compatibility.

OK, i thought you would offer a way to include extra files in the rhi installer. Currently the workflow is to create rhi, rename to zip, include extra files, rename to rhi, then publish. Have to admit, I never used yak. I’ll have to look into it and discuss with others. Double clicking the rhi was easy enough for most of the users.

No, if i have to make changes to those older V5 PlugIns i can still use the current compiler. I favor V6+ for all new PlugIns.

I have done something similar to make larger projects using modules “compilable” by automating a copy of the module code into every script. The difficulty was that the imports really need to be on top in order to find out which code (or individual function of a module) to include. The purpose of this was to have the module code encrypted along the regular script code. Just extracting the raw module code into a temp folder is problematic. I guess that purpose #1 of compiling a script into a PlugIn is to obscure the code and protect intellectual property.

thank you again for this great support, stay healthy !
_
c.

All plug-ins are compiled against the V6 SR0 version of RhinoCommon. Do you need to compile against other versions?

I still need to think about this a bit. My current plan is to embed everything into the rhp and provide some way for you to access and unpack these resources if you need to.

Temporarily creating and quickly deleting these files is probably the best I can do for now. I know this isn’t ideal for IP concerns, but it seems better than nothing

You too! My wife and I are doing well… apart from me driving her nuts :slight_smile:

1 Like

Oh, and @Jarek the new compiler will support transparent commands

1 Like

Are you 100% sure ? I thought the compiler uses the RhinoCommon.dll of the current Rhino installation (in case of V6). I had one case where the client was not able to use the compiled plugin. He was at SR12 and i was at SR21, so i needed to recompile using the RhinoCommon.dll for SR12. I mean the compiler Option in the PlugIn Settings > SDK.

Sounds interesting too. It would then require a re-compile if only a helpfile or toolbar has been changed. I guess there is no way around if those files can be included from within the compiler. But it makes testing with included (embedded) files harder. If a file can be physically copied to the PlugIn installation directory, it can be accessed by a (non compiled) script for testing. At least this is the way i test everything before i compile or update a PlugIn.

Risky if i can restore them. I was thinking like TestLoadEncryptedScript so they cannot be viewed as raw scripts. (This is for rvb)

_
c.

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

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.

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

+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.

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.

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?

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.

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

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

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

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

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

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…

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

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