Let’s hope so.
Let’s! Maybe this one could jump into your pile then ?
Can the compiler fuse this RUI-toolbar file I’ve create into the RHI-file automatically or will I have to rename it to zip, add the rui-file and the rename it back manually?
You’ll need to do the work manually for now. We can add this type of functionality in a future version of the compiler
It’s been a while since we have discussed this topic but I have an issue and I think you might be able to help me out.
Currently, my plug-in compilation process is finalized using scripts, and now I would like to automatize all that by using Jenkins. So I basically transferred my batch scripts and everything seems to work fine except for the compilation of my RHP with the RhinoScriptCompiler.exe, let me explain why.
It seems that the executable assumes that it has a “physical” console window opened and it tries to rescale it or at least graphically interact with it, which leads to a crash in Jenkins which is working in batch.
c:\test_jenkins\jenkins_workspace\workspace\RhinoPlugin>RhinoScriptCompiler.exe .\test.rhc Unhandled Exception: System.IO.IOException: The handle is invalid. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.__Error.WinIOError() at System.Console.set_CursorVisible(Boolean value) at RhinoScriptCompiler.Program.Main(String args)
When I try to do that manually on the physical machine (via RDP) in the console it works fine.
Do you think it could be possible to handle this case?
Is there a “full batch mode” for the RhinoScriptCompiler.exe?
Is the source code of the RhinoScriptCompiler.exe accessible?
Thanks in advance for your help!
In my code :
Set objXL = CreateObject(“Excel.Application”)
objXL.Visible = True
’ GAN GIA TRI TRONG EXCEL CHO BIEN
Dim i, A(12)
For i = 1 To 12 Step 1
A(i) = objXL.Worksheets(1).Cells(2 + i, 4).Value
It is Ok
But after I use RhinoScript compiler and run it had error
Do you close your file after creating it?
If not then that could explain why you can’t read it it
@stevebaer, i just re-post 3 wishes here in the hope that the compiler can get some love in the future:
- Please support / allow to include python modules
- Please allow to include custom files in the compiled rhi (rui, chm, pdf files etc)
- Please allow to control the compiled plugin version number
Maybe i misunderstand, but currently it is possible. RHI is just renamed ZIP, so if you open it using zip software, you can add any files you want. Or compile to rhp, and zip together with your files, then rename to rhi.
EDIT: unless you ask for ability to pick files from compiler project level for better automation. That indeed would be handy!
Hi @Jarek, that is the reason. Currently it makes a lot of work to update a plugin made of multiple scripts and other files without making errors. The most useful addition would be modules. I have a plugin with a dozen scripts which could all access a single module. To compile the scripts, i need to copy the module code into every script. If i update the module i need to repeat this again, so i have 2 versions of all scripts, the ones which are compilable (having the module code) and the ones which are not compileable and access the module in a regular way.
If i just could recompile the project and all files (scripts, chm, pdf…) referenced in my rhc project would be taken automatically, it would save a lot of time.
yeah, definitely! I also would find that very useful to automate packaging scripted plugins.
Ok, that’s jumping the gun a little bit We’re going to try and get an updated version of the Script Compiler in next week’s WIP.
Since I’m working on this project… how would you like to be able to work with things like chm and pdf files from your scripts? I understand the need for python library support (which is still something I’m hoping to add). I’m trying to figure out how these other embedded resources would be used.
Hi @stevebaer, thanks for looking into this again after such a long time.
I’ll try to explain first how i use aditional files in my scripts which i regularily compile into a single plugin file (rhi) using the RhinoScriptCompiler:
Pdf, Chm is used to provide helpfiles and documentation which are rolled out at every new PlugIn Release and get installed by the rhi installer. I always provide a toolbar file as well which contains buttons to open the help or documentation files. Here is the first hurdle to take, how to get the proper path to use as button command to open the helpfile ? I know how to get a relative path from a plugin of course, but if you have installed the rhi file multiple times, the version numbering is kind of random and makes it hard to figure out the proper pdf or chm file path.
Note that i regularily have to update all files which i include in the rhi file. So the second hurdle is, if a user just installs an updated rhi without manually removing the existing install, the installer creates a folder with a new version number and puts all files there. When Rhino 6 is then opened, the outdated toolbar is loaded, the updated one is ignored.
Another issue is that users are still able to choose the “All Users” and “Only me” option during the rhi installation. I had cases where the user just tried out both ways ending with multiple installs of the same PlugIn. You can repeat that simply by installing the same plugin multiple times, a new version numbered folder is created. This makes it very hard to find out where the helpfiles are located in order to open them. The company i work for has even provided PowerShell scripts to first remove old installs in order to prevent all of this, but some users never read help docs and therefore end with multiple PlugIn Installations, for multiple Rhino Versions.
As we all know, there have been major changes between V5 and V6 in regards to dimensions. Please, really Please provide a way so we can control for which Rhino version a compiled PlugIn (rhi and rhp) is allowed to be installed. It makes no sense to install my PlugIn in V6 and V7 if it deals with dimensions but was written for V5. Atm, all i (can) do is to check (in every compiled script) that the correct Rhino version is present. I would prefer to prevent the install before so i can get rid of all this code, which of course would be nice to put in a module or library.
I would kiss you then, but only if you’re not infectious. This is defenitely one of the most demanded things for me, even higher than having dockable WinForms.
One question about this statement. Does this mean that the compiler is no longer a seperate exe file and it only is included with the WIP ?
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 !
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
Oh, and @Jarek the new compiler will support transparent commands
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)